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(54) INFORMATION RECORDING/REPRODUCING APPARATUS AND METHOD 



(57) A block key to encrypt block data is generated 
using an ATS (arrival time stamp) appended to each of 
TS (transport stream) packets included in a transport 
stream correspondingly to the arrival time of the TS 
packet. The ATS is a random data depending upon an 
arrival time, and so a block-unique key can be generat- 
ed, which enhances the protection against data crypta- 



nalysis. A block key is generated from a combination of 
an ATS with a key unique to a device, recording medium 
or the like such as a master key, disc-unique key, title- 
unique key or the like. Since an ATS is used to generate 
a block key, any area for storage of an encryption key 
for each block may not be provided in a recording me- 
dium. 
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Description 

Technical Field 

[0001] The present invention relates generally to an 
information recorder, information player, information re- 
cording method, information playback method, informa- 
tion recording medium, and a program serving medium, 
and more particularly to an information recorder, infor- 
mation player, information recording method, informa- 
tion playback method, information recording medium, 
and a program serving medium, capable of preventing 
data from being illegally copied in data write to, and data 
read from, a recording medium to and from which data 
can be recorded and played back. 

Background Art 

[0002] With the recent advancement and develop- 
ment of the digital signal processing technology, digital 
recorders and recording media have been prevailing. 
With such a digital recorder and recording medium, an 
image or sound, for example, can be repeatedly record- 
ed and played back without any degradation thereof. 
Since digital data can be repeatedly copied many times 
with no degradation of the image and sound qualities, 
so recording media-having digital data illegally recorded 
therein, if put on the market, will cause the copyrighters 
of various contents such as music, movie, etc. or legal 
distributors of the contents to be deprived of profits 
which would come to the latter if such illegal copying is 
not possible. To prevent such illegal copying of digital 
data, various illegal-copy preventing systems have re- 
cently been introduced in digital recorders and recording 
media. 

[0003] As an example of the above illegal-copy pre- 
venting systems, SCMS (Serial Copy Management Sys- 
tem) is adopted in the MD (mini disc) drive (MD is a 
trademark) . The SCMS is such that at a data player side, 
audio data is outputted along with SCMS signal from a 
digital interface (DIF) while at a data recorder side, re- 
cording of the audio data from the data player side is 
controlled based on the SCMS signal from the data play- 
er side, thereby preventing the audio data from being 
illegally copied. 

[0004] More particularly, the above SCMS signal indi- 
cates that an audio data is a "copy-free" data which is 
allowed to freely be copied many times, a "copy-once- 
allowed" data which is allowed to be copied only once 
or a "copy-prohibited" data which is prohibited from be- 
ing copied. At the data recorder side, when receiving an 
audio data from the DIF, SCMS signal transmitted along 
with the audio data is detected. If the SCMS signal indi- 
cates that the audio data is a "copy-free" data, the audio 
data is recorded along with the SCMS signal to the mini 
disc. If the SCMS signal indicates that the audio data is 
a "copy-once-allowed" data, the audio data is converted 
to a "copy-prohibited" data and the SCMS signal is re- 



corded along with the audio data to the mini disc. Fur- 
ther, if the SCMS signal indicates that the audio data is 
a copy-prohibited data, the audio data is not recorded 
to the mini disc. Under a control with the SCMS signal, 
5 a copyrighted audio data is prevented from being ille- 
gally copied in the mini disc drive unit. 
[0005] However, the SCMS is valid only when the data 
recorder itself is constructed to control recording of au- 
dio data from the data player side based on the SCMS 
signal. Therefore, it is difficult for the SCMS to support 
a mini disc drive not constructed to perform the SCMS 
control. To apply the SCMS, a DVD player for example 
adopts a content scrambling system to prevent a copy- 
righted data from being illegally copied. 
[0006] The content scrambling system is such that en- 
crypted video data, audio data and the like are recorded 
in a DVD-ROM (read-only memory) and a decryption 
key for use to decrypt the encrypted data is given to each 
licensed DVD player. The license is granted to a DVD 
player designed in conformity with a predetermined op- 
eration rule against illegal copying etc. Therefore, using 
the given decryption key, a licensed DVD player can de- 
crypt encrypted data recorded in a DVD-ROM to thereby 
play back the video and audio data from the DVD-ROM . 
[0007] On the other hand, an unlicensed DVD player 
cannot decrypt encrypted data recorded in a DVD-ROM 
because it has no decryption key for the encrypted data. 
In short, the content scrambling system prevents a DVD 
player not meeting the licensing requirements from play- 
ing a DVD-ROM having digital data recorded therein in 
order to prevent illegal copying. 

[0008] However, the content scrambling system 
adopted in the DVD-ROM is directed to a recording me- 
dium to which the user cannot write data (will be referred 
to as "ROM medium" hereunder wherever appropriate), 
but not to any recording medium to which the user can 
write data (will be referred to as "RAM medium" here- 
under wherever appropriate). 

[0009] That is to say, copying all encrypted data re- 
corded in a ROM medium as they are to a RAM medium 
will produce a so-called pirated edition of the data which 
can be played back by a licensed DVD player. 
[0010] To solve the above problem, the Applicant of 
the present invention proposed, as disclosed in the Jap- 
anese Published Unexamined Application No. 224461 
of 1999 (Japanese Patent Application No. 25310 of 
1998), a method in which information to identify each 
recording medium (will be referred to as "medium ID in- 
formation" hereunder) is recorded with other data in a 
recording medium to allow access to the medium ID in- 
formation in the recording medium only when a player 
going to play the recording medium has been licensed 
for the medium ID information. 

[001 1 ] The above method encrypts data in the record- 
ing medium with a private key (master key) acquired 
through licensing of the medium ID information so that 
any unlicensed player cannot acquire any meaningful 
data even if it can read the encrypted data. Note that a 
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player licensed for the medium ID information has the 
operation thereof limited against illegal copying. 
[0012] No unlicensed player can access the medium 
ID information. The medium ID information is unique to 
each recording medium. Even if an unlicensed player 
could copy all encrypted data recorded in such a record- 
ing medium to a new recording medium, the data thus 
recorded in the new recording medium cannot correctly 
be decrypted by the unlicensed player as well as by a 
licensed player. Thus, it is substantially possible to pre- 
vent data from being illegally copied. 
[0013] Now it should be reminded thatthe method dis- 
closed in the above Japanese Published Unexamined 
Application No. 224461 of 1999 (Japanese Patent Ap- 
plication No. 25310 of 1998) uses a sector key unique 
to each sector of a disc to encrypt content data such as 
image, sound, program, etc. to be recorded to the disc. 
[001 4] The above method is destined to solve a prob- 
lem that if a large amount of data is encrypted with a 
single encryption key, the encryption key is likely to be 
uncovered by a differential attack or linear attack with a 
combination of an encrypted text stored in the recording 
medium and plain or unencrypted data acquired by an 
attacker by some means. In the method in the above 
Japanese Published Unexamined Application of the Ap- 
plicant of the present invention, a different encryption 
key is assigned to each of sectors of a predetermined 
size so that only a limited amount of data can be proc- 
essed with one encryption key, thereby making it difficult 
to disclose the encryption key. Further, the method can 
minimize the amount of data that can be decrypted if the 
encryption key is uncovered. 

[0015] In the example described in the above Japa- 
nese Published Unexamined Application, however, an 
encryption key (sector key) for each sector, used for en- 
cryption of a content, is further encrypted with a higher- 
order key and stored in a sector header of a recording 
medium. Thus, the recording medium has to provide an 
area wide enough to store the sector key in the sector 
header, and for recording or playing back the content, 
access has to be made to the sector header for writing 
(for recording) or reading (for playback) of the encrypted 
sector key. 

Disclosure of the Invention 

[0016] Accordingly, the present invention has an ob- 
ject to overcome the above-mentioned drawbacks of the 
prior art by providing an information recorder, informa- 
tion player, information recording method, information 
playback method, information recording medium and a 
program serving medium, in which block data can be 
encrypted with different encryption keys, respectively, 
to enhance the protection against cryptanalysis of the 
data without having to additionally provide any storage 
area for the encryption keys in a recording medium or a 
disc, namely, without narrowing an available data area 
in the recording medium. 



[0017] More particularly, the present invention has an 
object to provide an information recorder, information 
player, information recording method, information play- 
back method, information recording medium and a pro- 
5 gram serving medium, in which an arrival time stamp 
(ATS) formed as random data corresponding to an ar- 
rival time of each packet included in a transport stream 
of a data is used to generate a block key intended to 
encrypt a block data, thereby enhancing the protection 
10 against cryptanalysis of the data, and in which the ATS 
is used to generate a block key for each block without 
having to provide, in a recording medium, an additional 
area for storage of an encryption key for each block, 
thereby enabling an effective use of a main data area in 
15 the recording medium. 

[0018] According to the first aspect of the present in- 
vention, there can be provided an information recorder 
for recording information to a recording medium, the ap- 
paratus including: a transport stream processing means 
20 for appending an arrival time stamp (ATS) to each of 
discrete transport packets included in a transport 
stream; and a cryptography means for generating a 
block key for encrypting a block data including more 
than one transport packet each having the appended 
25 arrival time stamp (ATS) from a block seed which is ad- 
ditional information unique to the block data and includ- 
ing the arrival time stamp (ATS), and encrypting each 
block data with the block key thus generated; the data 
encrypted by the cryptography means being recorded 
30 to the recording medium. 

[0019] In the above information recorder according to 
the present invention, the cryptography means gener- 
ates the block key for encrypting the block data from a 
block seed which is additional information unique to the 
35 block data and including the arrival time stamp (ATS) 
appended to a leading one of the plurality of transport 
packets included in the block data. 
[0020] Further in the above information recorder ac- 
cording to the present invention, the cryptography 
40 means generates a title-unique key from a master key 
stored in the information recorder, a disc ID being a re- 
cording medium identifier unique to a recording medium 
and a title key unique to data to be recorded to the re- 
cording medium, and generates the block key from the 
45 title-unique key and block seed. 

[0021 ] Also in the above information recorder accord- 
ing to the present invention, the cryptography means 
generates a disc ID being a recording medium identifier 
unique to a recording medium and a title key unique to 
50 data to be recorded to the recording medium, and stores 
them into the recording medium. 
[0022] Further in the above information recorder ac- 
cording to the present invention , the block seed includes 
copy control information in addition to the arrival time 
55 stamp (ATS). 

[0023] Also in the above information recorder accord- 
ing to the present invention, in encryption of the block 
data, the cryptography means encrypts, with the block 
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key, only data included in the block data and excluding 
data in a leading area including a blockseed of the block 
data. 

[0024] Further in the above information recorder ac- 
cording to the present invention, the cryptography 
means generates a title-unique key from a master key- 
stored in the information recorder, a disc ID being a re- 
cording medium identifier uniqueto a recording medium 
and a title key unique to data to be recorded to the re- 
cording medium, takes the thus-generated title-unique 
key as a key for an encryption function, places the block 
seed into the encryption function, and outputs a result 
of the placement as a block key. 
[0025] Also in the above information recorder accord- 
ing to the present invention, the cryptography means 
generates a title-unique key from a master key stored 
in the information recorder, a disc ID being a recording 
medium identifier uniqueto a recording medium and a 
title key unique to data to be recorded to the recording 
medium, places the title-unique key thus generated and 
blockseed into a one-way function, and outputs a result 
of the placement as a block key. 
[0026] Further in the above information recorder ac- 
cording to the present invention, the cryptography 
means generates a device-unique key from any of an 
LSI key stored in an LSI included in the cryptography 
means, a device key stored-in the information recorder, 
a medium key stored in the recording medium and a 
drive key stored in a drive unit for the recording medium 
or a combination of these keys, and generates a block 
key for encrypting the block data from the device-unique 
key thus generated and block seed. 
[0027] Also in the above information recorder accord- 
ing to the present invention, the cryptography means 
encrypts .block data with the block key according to a 
DES algorithm. 

[0028] Further the above information recorder in- 
cludes an interface means for receiving information to 
be recordedto a recording medium, and identifying copy 
control information appended to each of packets includ- 
ed in the transport stream to judge, based on the copy 
control information, whether or not recording to the re- 
cording medium is allowed. 

[0029] Furthermore, the above information recorder 
includes an interface means for receiving information to 
be recorded to a recording medium, and identifying 2-bit 
EMI (encryption mode indicator) as copy control infor- 
mation to judge, based on the EMI, whether or not re- 
cording to the recording medium is allowed. 
[0030] According to the second aspect of the present 
invention, there can be provided an information player 
for playing back information from a recording medium, 
the apparatus including: a cryptography means for de- 
crypting encrypted data recorded in the recording me- 
dium by generating a block key for decrypting encrypted 
data in a block data having an arrival time stamp (ATS) 
appended to each of a plurality of transport packets from 
a block seed which is additional information unique to 



the block data and including the arrival time stamp 
(ATS), and decrypting each block data with the block 
key thus generated; and a transport stream processing 
means for controlling data output on the basis of the ar- 
5 rival time stamp (ATS) appended to each of the plurality 
of transport packets included in the block data having 
been decrypted by the cryptography means. 
[0031] In the above information player according to 
the present invention, the cryptography means gener- 
ates the block key for decrypting the block data from a 
block seed which is additional information unique to the 
block data and including the arrival time stamp (ATS) 
appended to a leading one of the plurality of transport 
packets included in the block data. 
[0032] Further in the above information player accord- 
ing to the present invention, the cryptography means 
generates a title-unique key from a master key stored 
in the information player, a disc ID being a recording me- 
dium identifier unique to a recording medium and a title 
key unique to data to be recorded to the recording me- 
dium, and generates the block key from the title-unique 
key and block seed. 

[0033] Further in the above information player accord- 
ing to the present invention, the block seed includes 
copy control information in addition to the arrival time 
stamp (ATS). 

[0034] Also in the above information player according 
to the present invention, in decryption of the block data, 
the cryptography means decrypts, with the block key, 
only data included in the block data and excluding data 
in a leading area including a block seed of the block da- 
ta. 

[0035] Further in the above informationplayer accord- 
ing to the present invention, the cryptography means 
generates a title-unique key. from a master key stored 
in the information player, a disc ID being a recording me- 
dium identifier unique to a recording medium and a title 
key unique to data to be recorded to the recording me- 
dium, takes the thus-generated title-unique key as a key 
for an encryption function, places the block seed into the 
encryption function, and outputs a result of the place- 
ment as a block key. 

[0036] Also in the above information player according 
to the present invention, the cryptography means gen- 
erates a title-unique key from a master key stored in the 
information player, a disc ID being a recording medium 
identifier unique to a recording medium and a title key 
unique to data to be recorded to the recording medium, 
places the title-unique key thus generated and block 
seed into a one-way function, and outputs a result of the 
placement as a block key. 

[0037] Further in the above information player accord- 
ing to the present invention, the cryptography means 
generates a device-unique key from any of an LSI key 
stored in an LSI included in the cryptography means, a 
device key stored in the information player, a medium 
key stored in the recording medium and a drive key 
stored in a drive unit forthe recording medium or a com- 
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bination of these keys, and generates a block key for 
decrypting the block data from the device-unique key 
thus generated and block seed. 
[0038] Also in the above information player according 
to the present invention, the cryptography means de- 
crypts block data with the block key according to a DES 
algorithm. 

[0039] Further the above information player includes 
an interface means for receiving information to be re- 
corded to a recording medium, and identifying copy con- 
trol information appended to each of packets included 
in the transport stream to judge, based on the copy con- 
trol information, whether or not playback from the re- 
cording medium is allowed. 

[0040] Furthermore, the above information player in- 
cludes an interface means for receiving information to 
be played back from a recording medium, and identify- 
ing 2-bit EMI (encryption mode indicator) as copy control 
information to judge, based on the EMI, whether or not 
playback the recording medium is allowed. 
[0041] According to the third another aspect of the 
present invention, there can be provided a method for 
recording information to a recording medium, the meth- 
od including the steps of: appending an arrival time 
stamp (ATS) to each of discrete transport packets in- 
cluded in a transport stream; and generating a block key 
for encrypting a block data including more than one 
transport packet each having the appended arrival time 
stamp (ATS) from a block seed which is additional infor- 
mation unique to the block data and including the arrival 
time stamp (ATS), and encrypting each block data with 
the block key thus generated; the data encrypted in the 
cryptographic step being recorded to the recording me- 
dium. 

[0042] In the above information recording method ac- 
cording to the present invention, in the cryptographic 
step, the block key for encrypting the block data is gen- 
erated from a block seed which is additional information 
unique to the block data and including the arrival time 
stamp (ATS) appended to a leading one of the plurality 
of transport packets included in the block data. 
[0043] Further in the above information recording 
method according to the present invention, in the cryp- 
tographic step, a title-unique key is generated from a 
master key stored in the information recorder, a disc ID 
being a recording medium identifier unique to a record- 
ing medium and a title key unique to data to be recorded 
to the recording medium, and the block key is generated 
from the title-unique key and block seed. 
[0044] Also the above information recording method 
according to the present invention includes the step of 
generating a disc ID being a recording medium identifier 
unique to a recording medium and a title key unique to 
data to be recorded to the recording medium, and stor- 
ing them into the recording medium. 
[0045] Also in the above information recording meth- 
od according to the present invention, in the crypto- 
graphic step, only data included in the block data and 



excluding data in a leading area including a block seed 
of the block data is encrypted with the block key. 
[0046] Further in the above information recording 
method according to the present invention, in the cryp- 
5 tographic step, a title-unique key is generated from a 
master key stored in the information recorder, a disc ID 
being a recording medium identifier unique to a record- 
ing medium and a title key unique to data to be recorded 
to the recording medium, the title-unique key thus gen- 
10 erated is taken as a key for an encryption function, the 
block seed is placed into the encryption function, and a 
result . of the placement. is outputted as a block key. 
[0047] Also in the above information recording meth- 
od according to the present invention, in the crypto- 
15 graphic step, a title-unique key is generated from a mas- 
ter key stored in the information recorder, a disc ID being 
a recording medium identifier unique to a recording me- 
dium and a title key unique to data to be recorded to the 
recording medium, the title-unique key thus generated 
20 and block seed are placed into a one-way function, and 
a result of the placement is outputted as a block key. 
[0048] Further in the above information recording 
method according to the present invention, in the cryp- 
tographic step, a device-unique key is generated from 
25 any of an LSI key stored in an LSI included in the cryp- 
tography means, a device key stored in an information 
recorder, a medium key stored in the recording medium 
and a drive key stored in a drive unit for the recording 
medium or a combination of any of these keys, and a 
30 block key for encrypting the block data is generated from 
the device-unique key thus generated and block seed. 
[0049] Also in the above information recording meth- 
od according to the present invention, in the crypto- 
graphic step, the block key-based block data encryption 
35 is made according to a DES algorithm. 

[0050] Further the above information recording meth- 
od includes the step of identifying copy control informa- 
tion appended to each of packets included in the trans- 
port stream to judge, based on the copy control infor- 
40 mation , whether or not recording to the recording medi- 
um is allowed. 

[0051] Furthermore, the above information recording 
method includes the step of identifying 2-bit EMI (en- 
cryption mode indicator) as copy control information to 
45 judge, based on the EMI, whether or not recording to 
the recording medium is allowed. 
[0052] According to the fourth aspect of the present 
invention, there can be provided a method for playing 
back information from a recording medium, the method 
50 including the steps of: generating a block key for de- 
crypting encrypted data in a block data having an arrival 
time stamp (ATS) appended to each of a plurality of 
transport packets from a block seed which is additional 
information unique to the block data and including the 
55 arrival time stamp (ATS), and decrypting each block da- 
ta with the block key thus generated; and controlling da- 
ta output on the basis of the arrival time stamp (ATS) 
appended to each of the plurality of transport packets 
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included in the block data having been decrypted in the 
decrypting step. 

[0053] In the above information playback method ac- 
cording to the present invention, in the decrypting step, 
the block key for decrypting the block data is generated 
from a blockseed which is additional information unique 
to the block data and including the arrival time stamp 
(ATS) appended to a leading one of the plurality of trans- 
port packets included in the block data. 
[0054] Further in the above information playback 
method according to the present invention, in the de- 
crypting step, a title-unique key is generated from a 
master key stored in the information player, a disc ID 
being a recording medium identifier unique to a record- 
ing medium and a title key unique to data to be recorded 
to the recording medium, and the block key is generated 
fromthetitle-unique key thus generated and blockseed. 
[0055] Also in the above information playback method 
according to the present invention, in decryption of the 
block data, only data included in the block data and ex- 
cluding data in a leading area including a block seed of 
the block data is decrypted with the block key. 
[0056] Further in the above information playback 
method according to the present invention, in the de- 
crypting step, a title-unique key is generated from a 
master key stored in the information player, a disc ID 
being a recording medium identifier unique to a record- 
ing medium and a title key unique to data to be recorded 
to the recording medium, the title-unique key thus gen- 
erated is taken as a key for an encryption function, the 
block seed is placed into the encryption function, and a 
result of the placement is outputted as a block key. 
[0057] Also in the above information playback mehod 
according to the present invention, in the decrypting 
step, a title-unique key is generated from a master key 
stored in the information player, a disc ID being a re- 
cording medium identifier uniqueto a recording medium 
and a title key unique to data to be recorded to the re- 
cording medium, the title-unique key thus generated 
and block seed are placed into a one-way function, and 
a result of the placement is outputted as a block key. 
[0058] Further in the above information playback 
method according to the present invention, in the de- 
crypting step, a device-unique key is generated from 
any of an LSI key stored in an LSI included in the cryp- 
tography means, a device key stored in the information 
player, medium key stored in the recording medium and 
a drive key stored in a drive unit for the recording medi- 
um or a combination of any of these keys, and a block 
key for decrypting the block data is generated from the 
device-unique key thus generated and the block seed. 
[0059] Also in the above information playback metnod 
according to the present invention, in the decrypting 
step, the block key-based block data decryption is made 
according to a DES algorithm. 

[0060] Further the above information playback meth- 
od includes the step of identifying copy control informa- 
tion appended to each of packets included in the trans- 



port stream to judge, based on the copy control infor- 
mation , whether or not playback from the recording me- 
dium is allowed. 

[0061] Furthermore, the above information playback 
5 method includes the step of identifying 2-bit EMI (en- 
cryption mode indicator) as copy control information to 
judge, based on the EMI, whether or not playback from 
the recording medium is allowed. 
[0062] According to the fifth aspect of the present in- 
fo vention, there can be provided a recording medium hav- 
ing recorded therein a block data including more than 
one packet included in a transport stream and having 
an arrival time stamp (ATS) appended to each of the 
packets, the block data including: an unencrypted data 
15 part having a block seed including the arrival time stamp 
(ATS) from which there is generated a block keyfor en- 
crypting the block data; and an encrypted data part hav- 
ing been encrypted with the block key. 
[0063] According to the sixth aspect of the present in- 
20 vention, there can be provided a program serving me- 
dium which serves a computer program under which re- 
cording of information to a recording medium is done in 
a computer system, the computer program including the 
steps of: appending an arrival time stamp (ATS) to each 
25 of discrete transport packets included in a transport 
stream; and generating a block key for encrypting a 
block data including more than one transport packet 
each having the appended arrival time stamp (ATS) 
from a block seed which is additional information unique 
30 to the block data and including the arrival time stamp 
(ATS), and encrypting each block data with the block 
key thus generated. 

[0064] According to the seventh aspect of the present 
invention, there can be provided a program serving me- 

35 dium which serves a computer program under which 
playback of information from a recording medium is 
done in a computer system, the computer program in- 
cluding the steps of: generating a block key for decrypt- 
ing encrypted data in a block data having an arrival time 

40 stamp (ATS) appended to each of a plurality of transport 
packets from a block seed which is block data unique 
additional information including the arrival time stamp 
(ATS), and decrypting each block data with the block 
key thus generated; and processing a transport stream 

45 to control data output on the basis of the arrival time 
stamp (ATS) appended to each of the plurality of trans- 
port packets included in the block data having been de- 
crypted in the decrypting step. 

[0065] According to the present invention, a content 
50 to be recorded to a recording medium is formed from of 
TS packets defined in the MPEG-2 and each packet is 
recorded to the recording medium along with an ATS 
being information on a time at which the packet has 
been received by a recorder. The "ATS" stands for ar- 
55 rival time stamp, and is a data of 24 to 32 bits. ATS is 
somewhat random. 

[0066] A number X of TS packets each having ATS 
appended thereto will be recorded in one block (sector) 
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of the recording medium, and ATS appended to the first 
TS packet is used to generate a block key for encrypting 
data in the block. 

[0067] Thus, data in each block can be encrypted with 
a unique block key without having to provide any special 
area for storage of the key and access any data other 
than main data during recording or playback. 
[0068] Further, in addition to ATS, copy control infor- 
mation (CCI) may be appended to a TS packet to be 
recorded and both the ATS and CCI be used to generate 
a block key. 

[0069] Note that the program serving media accord- 
ing to the sixth and seventh aspects of the present in- 
vention are for example a medium which serves a com- 
puter program in a computer-readable form to a general- 
purpose computer system capable of executing various 
program codes. The medium is not limited to any special 
form but it may be any of recording media such as CD, 
FD, MO, etc. and transmission media such as a network. 
[0070] The above program serving media define a 
structural or functional collaboration between a compu- 
ter program and medium to perform functions of a pre- 
determined computer program in a computer system. 
[0071] These objects and other objects, features and 
advantages of the present invention will become more 
apparent from the following detailed description of the 
preferred embodiments of the present invention when 
taken in conjunction with the accompanying drawings. 

Brief Description of the Drawings 

[0072] 

FIG. 1 is a block diagram showing a construction 

(1) of the information recorder/player according to 
the present invention. 

FIG. 2 is a block diagram showing a construction 

(2) of the information recorder/player according to 
the present invention. 

FIGS. 3A and 3B show flows of operations effected 
in a data recording process in the information re- 
corder/player according to the present invention. 
FIGS. 4A and 4B show flows of operations effected 
in a data playback process in the information re- 
corder/player according to the present invention. 
FIG. 5 explains a data format processed in the in- 
formation recorder/player according to the present 
invention. 

FIG. 6 is a block diagram showing the construction 
of a transport stream (TS) processing means in the 
information recorder/player according to the 
present invention. 

FIGS. 7A to 7C explain a transport stream proc- 
essed in the information recorder/player according 
to the present invention. 

FIG. 8 is a block diagram showing the construction 
of a transport stream (TS) processing means in the 
information recorder/player according to the 



present invention. 

FIG. 9 is a block diagram showing the construction 
of a transport stream (TS) processing means in the 
information recorder/player according to the 

5 present invention. 

FIG. 1 0 shows an example of additional information 
to the block data processed in the information re- 
corder/player according to the present invention. 
FIG. 11 is a block diagram (1) explaining the encryp- 

10 tion effected for data recording in the information 
recorder/player according to the present invention 
in a system with which the data has to be compati- 
ble. 

FIG. 12 is a block diagram (2) explaining the en- 
15 cryption effected for data recording in the informa- 
tion recorder/player according to the present inven- 
tion in a system with which the data has to be com- 
patible. 

FIG. 13 shows a flow of operations made in the en- 

20 cryption for data recording in the information record- 
er/player according to the present invention in a 
system with which the data has to be compatible. 
FIG. 14 explains how a block key is generated in 
the information recorder/player according to the 

25 present invention. 

FIG. 15 is a block diagram explaining the decryption 
effected for data playback in the information record- 
er/player according to the present invention in a 
system with which the data has to be compatible. 

30 FIG. 1 6 shows a flow of operations made in the de- 
cryption for data playback in the information record- 
er/player according to the present invention in a 
system with which the data has to be compatible. 
FIG. 17 is a block diagram explainingthe encryption 

35 for data recording in the information recorder/player 
according to the present invention in a system with 
which the data has not to be compatible. 
FIG. 18 shows a flow of operations effected in the 
encryption for data recording in the information re- 

40 corder/player according to the present invention in 
a system with which the data has not to be compat- 
ible. 

FIG. 19 is a block diagram explaining an example 

(1) of device-unique key generation in the informa- 
45 tion recorder/player according to the present inven- 
tion in a system with which the data has not to be 
compatible. 

FIG. 20 is a block diagram explaining an example 

(2) of device-unique key generation in the informa- 
50 tion recorder/player according to the present inven- 
tion in a system with which the data has not to be 
compatible. 

FIG. 21 is a block diagram explainingthe decryption 
for data playback in the information recorder/player 
55 according to the present invention in a system with 
which the data has not to be compatible. 
FIG. 22 shows a flow of operations effected in the 
decryption for data playback in the information re- 
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corder/player according to the present invention in 
a system with which the data has not to be compat- 
ible. 

FIG. 23 is a block diagram (1) explaining the en- 
cryption for data recording in the information record- 5 
er/player according to the present invention in a 
system in which a player restriction can be set. 
FIG. 24 is a block diagram (2) explaining the en- 
cryption for data recording in the information record- 
er/player according to the present invention in a 10 
system in which the player restriction can be set. 
FIG. 25 shows a flow of operations effected in the 
data recording in the information recorder/player 
according to the present invention in a system in 
which the player restriction can be set. 15 
FIG. 26 explains an example of disc-unique key 
generation in the information recorder/player ac- 
cording to the present invention. 
FIG. 27 shows a flow of operations effected in gen- 
eration of title-unique key in the information record- 20 
er/player according to the present invention in a 
system in which the player restriction can be set. 
FIG. 28 shows an example of title-unique key gen- 
eration for data recording in the information record- 
er/player according to the present invention in a 25 
system in which the player restriction can be set. 
FIG. 29 is a block diagram explaining the decryption 
for data playback in the information recorder/player 
according to the present invention in a system in 
which the player restriction can be set. 30 
FIG. 30 shows a flow of operations effected in the 
data playback in the information recorder/player ac- 
cording to the present invention in a system in which 
the player restriction can be set. 
FIG. 31 is a flow chart showing in detail a judgment, 35 
in data playback, of whether or not data can be 
played back in the information recorder/player ac- 
cording to the present invention in a system in which 
the player restriction can be set. 
FIG. 32 shows a flow of operations effected in gen- 40 
eration of title-unique key for data playback in the 
information recorder/player according to the 
present invention in a system in which the player 
restriction can be set. 

FIGS. 33A and 33B showflows of operations effect- 45 
ed for copy control in the data recording in the in- 
formation recorder/player according to the present 
invention. 

FIGS. 34A and 34B showflows of operations effect- 
ed for copy control in the data playback in the infor- 50 
mation recorder/player according to the present in- 
vention. 

FIG. 35 is a block diagram of a data processing sys- 
tem to process data by software in the information 
recorder/player. 55 



Best Mode for Carrying Out the Invention 
[System configuration] 

[0073] Referring now to FIG. 1 , there is schematically 
illustrated in the form of a block diagram an embodiment 
of the information recorder/player according to the 
present invention. The recorder/player is generally indi- 
cated with a reference 100. As shown, the recorder/ 
player 100 includes an input/output interface (l/F) 120, 
MPEG (Moving Picture Experts Group) codec 130, in- 
put/output l/F 140 including an A/D converter and D/A 
converter combination 141, cryptography unit 150, 
ROM (read-only memory) 160, CPU (central processing 
unit) 1 70, memory 1 80, drive 1 90 for a recording medi- 
um 1 95, and a transport stream processing means (TS 
processor) 300. The components are connected to each 
other by a bus 110. 

[0074] The in/output l/F 120 receives digital signals 
included in each of various contents such as image, 
sound, program or the like supplied from outside, and 
outputs them to the bus 110 and also to outside. The 
MPEG codec 1 30 makes MPEG decoding of MPEG-en- 
coded data supplied via the bus 110, and outputs the 
MPEG-decoded data to the input/output l/F 140 while 
making MPEG encoding of digital signals supplied from 
the input/output l/F 1 40 and outputs the data to the bus 
110. The input/output l/F 1 40 incorporates the A/D con- 
verter and D/A converter combination 141. The input/ 
output l/F 140 receivers analog signals as a content 
from outside, makes A/D (analog-to-digital) conversion 
of the data and outputs digital signals thus obtained to 
the MPEG coder 130, while making D/A (digital-to-ana- 
log) conversion of digital signals from the MPEG codec 
1 30 and outputs analog signals thus obtained to outside. 
[0075] The cryptography unit 150 is a one-chip LSI 
(large scale integrated circuit) for example. It encrypts 
or decrypts digital signals in a content supplied via the 
bus 110, and outputs the data to the bus 110. Note that 
the cryptography unit 150 is not limited to the one-chip 
LSI but may be a combination of various types of soft- 
ware or hardware. A software-type cryptography unit will 
further be described later. 

[0076] The ROM 1 60 has stored therein a device key 
unique to for example each recorder/player or a group 
of a plurality of recorders/players. The CPU 170 exe- 
cutes a program stored in the memory 1 80 to control the 
MPEG codec 130, cryptography unit 150, etc. The mem- 
ory 1 80 is for example a nonvolatile memory to store for 
example a program to be executed by the CPU 1 70 and 
necessary data for operation of the CPU 1 70. The drive 
1 90 drives the recording medium 1 95 capable of record- 
ing digital data to read digital data from the recording 
medium 1 95 and outputs the data to the bus 1 1 0 while 
supplying digital data supplied via the bus 1 1 0 to the re- 
cording medium 1 95 for recording to the latter. Note that 
the recorder/player 1 00 may be constructed so that the 
ROM 160 stores the program while the memory 180 
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stores the device keys. 

[0077] The recording medium 1 95 is a medium capa- 
ble of storing digital data, such as one of optical discs 
including a DVD, CD and the like, a magneto-optical 
disc, a magnetic disc, a magnetic tape or one of semi- 
conductor memories including a RAM and the like. In 
this embodiment, the recording medium 195 is remov- 
ably installable in the drive 1 90. Note however that the 
recording medium 195 may be incorporated in the re- 
corder/player 1 00. 

[0078] The transport stream processing means (TS 
processor) 300 extracts transport packets correspond- 
ing to a predetermined program (content) from, for ex- 
ample, a transport stream having a plurality of TV pro- 
grams (contents) multiplexed therein, stores information 
on a time of appearance of the extracted transport 
stream appears along with each packet into the record- 
ing medium 195, and controls the time of appearance 
of a transport stream for reading from the recording 
means 195. The TS processor 300 will further be de- 
scribed later with FIG. 6 and subsequent drawings. 
[0079] For a transport stream, there is set an ATS (ar- 
rival time stamp) as a time of appearance of each of 
transport packets in the transport stream. The time of 
appearance is determined during encoding not to cause 
a failure of a T-STD (transport stream system target de- 
coder) being a virtual decoder defined in the MPEG-2 
Systems, and during read of a transport stream, the time 
of appearance is controlled with an ATS appended to 
each of transport packets. The TS processor 300 per- 
forms the above kinds of control. For example, in record- 
ing of transport packets to the recording medium, the 
transport packets are recorded as source packets ar- 
ranged with no space between successive packets and 
the time of appearance of each packet kept unchanged, 
which enables to control the output timing of each trans- 
port packet during read from the recording medium. The 
TS processor 300 appends ATS (arrival time stamp) in- 
dicative of a time at which each of transport packets has 
been received, when data is recorded to the recording 
medium 195 such as a DVD. 

[0080] In the recorder/player 100 according to the 
present invention , a content including a transport stream 
in which the ATS is appended to each of transport pack- 
ets is encrypted by the cryptography unit 150, and the 
content thus encrypted is stored into the recording me- 
dium 195. Further, the cryptography unit 150 decrypts 
an encrypted content stored in the recording medium 
1 95. These encryption and decryption will further be de- 
scribed later. 

[0081] Note that in FIG. 1, the cryptography unit 150 
and TS processor 1 30 are shown as separate blocks for 
the convenience of the illustration and explanation but 
these functions may be incorporated in a one-chip LSI 
or performed by a combination of software or hardware 
pieces. 

[0082] In addition to the construction shown in FIG. 1 , 
the recorder/player according to the present invention 



may be constructed as in FIG. 2. The recorder/player 
shown in FIG. 2 is generally indicated with a reference 
200. In the recorder/player 200, a recording medium 195 
is removably installable in a recording medium interface 

5 (l/F) 210 as a drive unit. Write and read of data to and 
from the recording medium 1 95 are also possible when 
it is used in another recorder/player. In the recorder/ 
player as shown in FIG. 2, in which the recording medi- 
um 195 compatible with more than one recorder/player 

10 can be used, a device key unique to each recorder/play- 
er is not used but a common key to all such recorder/ 
players, that is, a common key to the entire system, is 
stored in the memory 180. 

15 [Data recording and playback] 

[0083] Referring now to FIGS. 3 and 4, there are 
shown flows of operations effected in data write to the 
recording medium in the recorder/player shown in FIG. 

20 1 or 2, and in data read from the recording medium. For 
recording digital signals as a content from outside to the 
recording medium 195, operations are effected as 
shown in the flow chart in FIG. 3A. Namely, when digital 
signals as a content (digital content) is supplied to the 

25 input/output l/F 120 via an IEEE (Institute of Electrical 
and Electronics Engineers) 1394 serial bus or the like, 
the input/output l/F 120 will receive the digital content 
and outputs the data to the TS processor 300 via the 
bus 110 in step S301 . 

30 [0084] In step S302, the TS processor 300 generates 
block data in which an ATS is appended to each of trans- 
port packets in a transport stream, and outputs the data 
to the cryptography unit 1 50 via the bus 1 1 0. 
[0085] In step S303, the cryptography unit 150 en- 

35 crypts the received digital content, and outputs the en- 
crypted content to the drive 1 90 or recording medium I/ 
F 21 0 via the bus 110. In step S304, the encrypted digital 
content is recorded to the recording medium 1 95 via the 
drive 1 90 or recording medium l/F 21 0. Here the record- 

40 er/player exits the recording procedure. The encryption 
by the cryptography unit 150 will further be described 
later. 

[0086] It should be reminded that as a standard to pro- 
tect the digital content transmitted between the devices 

45 via the IEEE 1394 serial bus, "SCDTCP (Five Company 
Digital Transmission Content Protection)" (will be re- 
ferred to as "DTCP" hereunder) was established by the 
five companies including the Sony Corporation being 
the Applicant of the present invention. It prescribes that 

50 in case a digital content not being any "copy-free" one 
is transmitted between devices, the transmitter and re- 
ceiver sides should mutually authenticate, before the 
transmission, that copy control information can correctly 
be handled, then the digital content be encrypted at the 

55 transmitting side for transmission thereof and the en- 
crypted digital contact (encrypted content) be decrypted 
at the receiving side. 

[0087] In data transmission and reception under this 
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DTCP standard, the input/output l/F 210 at the data re- 
ceiver side receives the encrypted content via the IEEE 
1394 serial bus, decrypts the encrypted content in con- 
formity with the DTCP standard, and then outputs the 
data as a plain or unencrypted content to the cryptogra- 
phy unit 150 (in step S301). 

[0088] For the DTCP-based encryption of a digital 
content, a time-varying key is to be generated. The en- 
crypted digital content including the encryption key hav- 
ing been used for the encryption is transmitted over the 
IEEE 1493 serial bus to the receiver side, and the re- 
ceiver side decrypts the encrypted digital content with 
the key included in the content. 

[0089] More precisely, the DTCP standard prescribes 
that an initial value of the key and a flag indicative of a 
time of changing the key for encryption of digital content 
are included in the encrypted content. At the receiving 
side, the initial value of the key included in the encrypted 
content is changed with the timing indicated by the flag, 
included in the encrypted content, to generate a key 
having been used for the encryption, and the encrypted 
content is decrypted with the key thus generated. Name- 
ly, it may be considered that the encrypted content in- 
cludes a key used to decrypt it, and so this consideration 
shall also be true in the following description. According 
to the DTCP standard, an informational version is avail- 
able from for example a Web page identified by URL 
(uniform resource locator) of http://www.dtcp.com. 
[0090] Next, write of external analog signals as a con- 
tent to the recording medium 1 95 will be described with 
reference to the flow chart in FIG. 3B. When the input/ 
output l/F 1 40 receives analog signals as a content (an- 
alog content) in step S321 , it goes to step S322 where 
the A/D converter and D/A converter combination 141 
will make A/D conversion of the analog content to pro- 
vide digital signals as a content (digital content). 
[0091] The digital content is supplied to the MPEG co- 
dec 1 30 which will make MPEG encoding of the digital 
content, namely, encoding of the digital content by 
MPEG compression, in step S323 and supply the en- 
coded content to the cryptography unit 150 via the bus 
110. 

[0092] In subsequent steps S324, S325 and S326, 
similar operations to those in S302 and S303 in FIG. 3A 
are effected. That is, the TS processor 300 appends 
ATS to each of transport packets, the cryptography unit 
150 encrypts the content, and the encrypted content 
thus obtained is recorded to the recording medium 1 95. 
Here the recorder/player exists the recording proce- 
dure. 

[0093] Next, a flow of operations effected for playing 
back the content from the recording medium 195 and 
outputting it as a digital or analog content to outside will 
be described with reference to the flow chart in FIG. 4. 
This is done as in the-flow chart in FIG. 4A. First in step 
S401 , an encrypted content is read from the recording 
medium 195 by the drive 190 or recording medium l/F 
21 0, and outputted to the cryptography unit 1 50 via the 



bus 110. 

[0094] In step S402, the cryptography unit 150 de- 
crypts the encrypted content supplied from the drive 1 90 
or recording medium l/F 21 0, and outputs the decrypted 
5 data to the TS processor 300 via the bus 110. 

[0095] In step S403, the TS processor 300 deter- 
mines the timing of output based on the ATS appended 
to each of the transport packets included in the transport 
stream to make a control corresponding to the ATS, and 
supplies the data to the input/output l/F 1 20 via the bus 
110. Note that the processing operations of theTS proc- 
essor 300 and decryption of the digital content in the 
cryptography unit 150 will further be described later. 
[0096] Note that when the digital content is outputted 
via the IEEE 1394 serial bus, the input/output l/F 120 
makes a mutual authentication with a counterpart de- 
vice as previously mentioned in conformity with the 
DTCP standard in step S404, and then encrypts the dig- 
ital content for transmission. 

[0097] For reading a content from the recording me- 
dium 195 and outputting it as an analog content to out- 
side, playback operations are done as in the flow chart 
shown in FIG. 4B. 

[0098] Namely, similar operations to those in steps 
S401 , S402 and S403 in FIG. 4A are effected in subse- 
quent steps S421, S422 and S423. Thereby, the de- 
crypted digital content provided from the cryptography 
unit 1 50 is supplied to the MPEG codec 1 30 via the bus 
110. 

[0099] In step S424, the MPEG codec 130 makes 
MPEG decoding of the digital content, namely, expands 
the digital data, and supplies the data to the input/output 
l/F 140. In step S425, the input/output l/F 140 makes D/ 
A conversion of the digital content having been subject- 
ed to the MPEG decoding in the MPEG codec 130 in 
step S424 by the A/D converter and D/A converter com- 
bination 1 41 . Then the input/output l/F 1 40 goes to step 
S426 where it will output the analog content to outside. 
Here the recorder/player exits the playback procedure. 

[Data format] 

[01 00] Next, the format of data written to or read from 
the recording medium according to the present inven- 
tion will be described with reference to FIG. 5. The min- 
imum unit in which data is read from or written to the 
recording medium according to the present invention is 
called "block". One block has a size of 192*X bytes (e. 
g.,X = 32). 

[0101] According to the present invention, an ATS is 
appended to each MPEG2-defined TS (transport 
stream) packet (of 1 88 bytes) to provide a data of 1 92 
bytes, and a number X of such data are taken as one 
block. The ATS is a data of 24 to 32 bits indicating an 
arrival time. ATS stands for "arrival time stamp" as hav- 
ing previously been described. The ATS is a random da- 
ta corresponding to an arrival time of each packet. One 
block (sector) of the recording medium records a 
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number X of TS (transport stream) packets each having 
an ATS appended thereto. According to the present in- 
vention, an ATS appended to the first one of TS packets 
in each of blocks included in a transport stream is used 
to generate a block key which is used to encrypt the data 
in the block (sector). 

[0102] A unique key for each of the blocks is gener- 
ated by generating an encrypting block key based on 
the random ATS. The block-unique key thus generated 
is used to encrypt each block. Also, by generating a 
block key based on the ATS, it is made unnecessary to 
provide an area in the recording medium for storage of 
the encryption key for each block and it becomes pos- 
sible to effectively use the main data area in the record- 
ing medium. Further, during data playback, it is not nec- 
essary to access data other than in the main data area, 
which will assure a more efficient data recording or play- 
back. 

[0103] Note that a block seed shown in FIG. 5 is ad- 
ditional information including ATS. The block seed may 
also include copy control information (CCI) in addition 
to ATS. In this case, ATS and CCI are used to generate 
a block key. 

[0104] Note that according to the present invention, 
the majority of data in a content stored into the recording 
medium such as a DVD is encrypted. As shown in the 
bottom of FIG. 5, m bytes (m = 8 or 1 6 bytes for example) 
in the leading portion of a block are recorded as plain or 
unencrypted data, namely, not encrypted, while the re- 
maining data (m+1 and subsequent) is encrypted be- 
cause the encrypted data length is limited since the en- 
cryption is made in units of 8 bytes. Note that if the en- 
cryption may be effected in 1 -byte units for example, not 
in 8-byte units, all the data except for the block seed 
may be encrypted with four bytes set in the leading por- 
tion of the block (m = 4). 

[Operations by the TS processor] 

[0105] The function of ATS will be described in detail 
herebelow. As having previously been described, the 
ATS is an arrival time stamp appended to each of trans- 
port packets included in an inputtransport stream to pre- 
serve a timing of appearance of the TS packet. 
[0106] That is, when one or some is extracted from a 
plurality of TV programs (contents) multiplexed in a 
transport stream, for example, transport packets includ- 
ed in the extracted transport stream appear at irregular 
intervals (see FIG. 7A). A timing in which each of the 
transport packets in a transport stream appears is im- 
portant for the transport stream, and the timing of ap- 
pearance is determined during encoding not to cause 
any failure of T-STD (transport stream system target de- 
coder) being a virtual decoder defined in the MPEG-2 
Systems (ISO/IEC 13818-1). 

[0107] During playback of the transport stream, the 
timing of appearance is controlled based on the ATS ap- 
pended to each transport packet. Therefore, when re- 



cording the transport packets to the recording medium, 
the input timing of the transport packet has to be pre- 
served. When recording transport packets to a record- 
ing medium such as a DVD, an ATS indicative of the 
5 input timing of each transport packet is appended to the 
transport packet which is to be recorded to the recording 
medium. 

[0108] FIG. 6 is a block diagram explaining the oper- 
ations effected in the TS processor 300 when recording 

10 a transport stream supplied via a digital interface to a 
recording medium such as a DVD. As shown, the trans- 
port stream is supplied as digital data such as digital 
broadcast signals from a terminal 600 to the TS proces- 
sor 300. As shown in FIG. 1 or 2, the transport stream 

15 is supplied from the terminal 600 via the input/output I/ 
F 120 or the input/output l/F 140 and MPEG codec 130. 
[01 09] The transport stream is supplied to a bit stream 
parser 602 which will detect a PCR (program clock ref- 
erence) packet in the inputtransport stream. The PCR 

20 packet is a packet in which PCR defined in the MPEG- 
2 Systems is encoded. The PCR packets have been en- 
coded at time intervals of less than 1 00 msec. The PCR 
represents a time when a transport packet arrives at the 
receiving side with an accuracy of 27 MHz. 

25 [0110] Then, a 27-MHz PLL 603 locks a 27-MHz clock 
of the recorder/player to the PCR of the transport 
stream. A time stamp generation circuit 604 generates 
a time stamp based on a count of 27-MHz clocks. A 
block seed appending circuit 605 appends a time stamp, 

30 indicative of a time when the first byte of the transport 
packet is inputted to a smoothing buffer 606, as ATS to 
the transport packet. 

[0111] The transport packet having ATS appended 
thereto is outputted from a terminal 607 through the 
35 smoothing buffer 606 to the cryptography unit 150 
where it will be encrypted as will further be described, 
and then recorded to the recording medium 1 95 via the 
drive 190 (in FIG. 1) and recording medium l/F 210 (in 
FIG. 2). 

40 [0112] FIG. 7 shows, by way of example, operations 
effected for recording an input transport stream to the 
recording medium. FIG. 7A shows input of transport 
packets included in a certain program (content). The 
horizontal axis in the FIG. 7A is a time base indicative 

45 of a time of the transport stream. In this embodiment, 
transport packets in the input transport stream appear 
at irregular times as shown in FIG. 7A. 
[0113] FIG. 7B shows an output of the block seed ap- 
pending circuit 605. This block seed appending circuit 

50 605 appends a block seed including an ATS indicating 
an arrival time of each of transport packets in a transport 
stream to the transport packet, and outputs a source 
packet. FIG. 7C shows source packets recorded in the 
recording medium. The source packets are recorded to 

55 the recording medium with no space between succes- 
sive packets as shown in FIG. 7C. Owing to this arrange- 
ment of the source packets with no space between 
them, the recording area in the recording medium can 
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be used effectively. 

[0114] FIG. 8 is a block diagram of the TS processor 
300, showing a data processing procedure to read a 
transport stream from the recording medium 195. A 
transport packet having been decrypted in a cryptogra- 
phy unit which will further be described later and having 
an ATS appended thereto is supplied from a terminal 
800 to a block seed separation circuit 801 where the 
ATS and transport packet will be separated from each 
other. There is provided a timing generation circuit 804 
to compute a time based on a clock count of a 27-MHz 
clock 805 of the player. 

[0115] Note that the first ATS is set as an initial value 
in the timing generation circuit 804. There is also pro- 
vided a comparator 803 to compare the ATS with a cur- 
rent time supplied from the timing generation circuit 804. 
Also an output control circuit 802 is provided to output 
the transport packet to the MPEG codec 130 or digital 
input/output l/F 1 20 when a timing generated by the tim- 
ing generation circuit 804 becomes equal to the ATS. 
[0116] FIG. 9 shows MPEG encoding of input AV sig- 
nals in the MPEG codec 1 30 of the recorder/player 1 00 
and encoding of the transport stream in the TS proces- 
sor 300. Namely, FIG. 9 is a block diagram of operations 
effected in both the MPEG codec 130 in FIG. 1 or FIG. 
2 and TS processor 300. Video signals are supplied 
from a terminal 901 to an MPEG video encoder 902. 
[0117] The MPEG video encoder 902 encodes the in- 
put video signals to an M PEG video stream, and outputs 
the data to a video stream buffer 903. Also, the MPEG 
video encoder 902 outputs access unit information on 
the MPEG video stream to a multiplexing scheduler 908. 
The "access unit" of video stream includes a type, en- 
coded bit amount and decode time stamp of each pic- 
ture. The "picture type" is information on an l/P/B pic- 
ture, and the "decode time stamp" is information defined 
in the MPEG-2 Systems. 

[0118] There are supplied audio signals from an ter- 
minal 904 to an MPEG audio encoder 905. The MPEG 
audio encoder 905 encodes the input audio signals to 
an MPEG audio stream and outputs the data to a buffer 
906. The MPEG audio encoder 905 outputs also access 
unit information on the MPEG audio stream to the mul- 
tiplexing scheduler 908. The "access unit" of the audio 
stream is an audio frame, and the access unit informa- 
tion includes an encoded bit amount and decode time 
stamp of each audio frame. 

[0119] The multiplexing scheduler 908 is supplied 
with both the video and audio access information, and 
controls encoding of the video and audio streams based 
on the access unit information. The multiplexing sched- 
uler 908 incorporates a clock to generate a reference 
time with an accuracy of 27 MHz, and thus determines 
packet encoding control information for the transport 
packet according to theT-STD which is a virtual decoder 
model defined in the MPEG-2. The packet encoding 
control information includes the type and length of a 
stream to be packetized. 



[0120] In case the packet encoding control informa- 
tion is video packets, a switch 976 is placed at a side a 
thereof to read, from the video stream buffer 903, video 
data of a payload data length designated by the packet 
5 encoding control information and supply the data to a 
transport packet encoder 909. 

[0121] In case the packet encoding control informa- 
tion is audio packets, the switch 976 is placed at a side 
b thereof to read, from the audio stream buffer 906, au- 
dio data of a designated payload data length, and supply 
the data to the transport packet encoder 909. 
[0122] In case the packet encoding control informa- 
tion is PCR packets, the transport packet encoder 909 
acquires PCR supplied from the multiplexing scheduler 
908 and outputs PCR packets to outside. To indicate 
that the packet encoding control information will not en- 
code packets, nothing is supplied to the transport packet 
encoder 909. 

[0123] For an indication thatthe packet encoding con- 
trol information will not encode packets, the transport 
packet encoder 909 outputs no packets. In other case, 
transport packets are generated based on the packet 
encoding control information and outputted. Therefore, 
the transport packet encoder 909 outputs transport 
packets intermittently. Also there is provided an arrival 
time stamp calculator 91 0 to calculate ATS indicative of 
a time at which the first byte of a transport packet arrives 
at the receiving side, based on the PCR supplied from 
the multiplexing scheduler 908. 

[0124] Since PCR supplied from the multiplexing 
scheduler 908 indicates a time at which the tenth byte 
of a transport packet defined in the MPEG-2 arrives at 
the receiving side, so the value of an ATS is a time at 
which a byte 1 0 bytes before the time indicated by PCR. 
[0125] A block seed appending circuit 911 appends 
an ATS to each of packets outputted from the transport 
packet encoder 909. An ATS-appended transport pack- 
et outputted from the block seed appending circuit 911 
is supplied to the cryptography unit 150 through a 
smoothing buffer 912 where it will be encrypted as will 
further be described later and then stored into the re- 
cording medium 195. 

[0126] For storage into the recording medium 195, the 
ATS-appended transport packets are arranged with no 
space between them as shown in FIG. 7C and then 
stored into the recording medium 195 before subjected 
to encryption in the cryptography unit 150. Even if the 
transport packets are arranged with no space between 
them, reference to the ATS appended to each of the 
packets makes it possible to control the time of supply- 
ing the transport packets to the receiving side. 
[01 27] Note that the size of ATS is not fixed to 32 bits 
but it may be within a range of 24 to 32 bits. The longer 
the bit length of ATS, the longer the operating cycle of 
the ATS time counter is. For instance, in case the ATS 
time counter is a binary counter whose ATS counting 
accuracy is 27 MHz, an ATS of 24 bits in length will ap- 
pear again in about 0.6 sec. This time interval is long 
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enough for an ordinary transport stream because the 
packet interval of a transport stream is defined to be 0.1 
sec at maximum by the MPEG-2. However, the bit length 
of ATS may be more than 24 bits for a sufficient allow- 
ance. 

[0128] By varying the bit length of ATS as in the 
above, the blockseed being an additional data to a block 
data can be configured in some types. Example config- 
urations of the block seed are shown in FIG. 1 0. Exam- 
ple 1 shown in FIG. 1 0 is a block seed using an ATS of 
32 bits in length. Example 2 in FIG. 1 0 is a block seed 
using an ATS of 30 bits and copy control information 
(CCI) of 2 bits. The copy control information indicates a 
controlled state of copying of data having the CCI ap- 
pended thereto. SCMS (serial copy management sys- 
tem) and CGMS (copy generation management system) 
are most well-known as copy control information. These 
copy control information indicate that data having the 
copy control information appended thereto is allowed to 
limitlessly be copied (copy-free), the data is allowed to 
be copied only for one generation (one-generation- 
copy-allowed) or that the data is prohibited from being 
copied (copy-prohibited). 

[0129] An example 3 shown in FIG. 10 is a blockseed 
using ATS of 24 bits, CCI of 2 bits and other information 
of 6 bits. The other information may be selected from 
various kinds of information such as information indicat- 
ing on/off operation of a Macrovision which is a copy 
control mechanism for analog video data when the block 
seed data is outputted in an analog form. 

[Encryption in data recording in a system with which 
recorded data has to be compatible] 

[0130] Next, there will be described an encryption to 
be effected in data recording in a system with which re- 
corded data has to be compatible, namely, in a system 
in which a recording medium having data recorded 
therein in a recorder/player has to be playable in another 
recorder/player. The system with which recorded data 
has to be compatible is the recorder/player 200 for ex- 
ample as shown in FIG. 2. That is, the recording medium 
195 having data recorded therein by the recorder/player 
200 has to be playable in another recorder/player. 
[0131] The encryption effected in data recording in 
such a system will be described with reference to the 
blockdiagrams in FIGS. 11 and 12 and flowchart in FIG. 
1 3. An optical disc will be taken herebelow as an exam- 
ple of the recording medium. This embodiment is a sys- 
tem with which recorded data has to be compatible, that 
is, a system in which data recorded in a recorder/player 
has to be playable back in another recorder/player, as 
in the Japanese Published Unexamined Application No. 
224461 of 1999 (Japanese Patent Application No. 
2531 0 of 1 998). In order to prevent data in the recording 
medium from being bit-by-bit copied, disc ID as record- 
ing medium-unique identification information is made to 
act on a data encryption key. 



[0132] The data encryption by the cryptography unit 
150 will be outlined herebelow with reference to the 
block diagrams in FIGS. 11 and 12. 
[0133] A recorder/player 1100 reads a master key 

5 1101 stored in its own memory 180 (as shown in FIG. 
2). The master key 1101 is a private key stored in a li- 
censed recorder/player, and also a common key to a 
plurality of recorder/players, namely, to an entire sys- 
tem. The recorder/player 1100 checks if a disc ID 1103 

10 as identification information is already recorded in a re- 
cording medium 1 1 20 which is an optical disc for exam- 
ple. If the disc ID 1103 is found recorded in the recording 
medium 1120, the recorder/player 1100 reads the disc 
ID 1103 (as in FIG. 11). If not, the cryptography unit 150 

15 in the recorder/player 1100 generates a disc ID 1201 at 
random or by generating a predetermined random 
number, and records the disc ID 1201 to the disc (as in 
FIG. 12). For each disc, there has to be available only 
one such disc ID 1 1 03, and so the disc ID can be stored 

20 in the lead-in area or the like of the disc. 

[0134] Next, the recorder/player 1100 generates a 
disc-unique key 1102 from the master key and disc ID 
(as indicated at a reference 1 1 02). More particularly, the 
disc-unique key is generated for example by placing da- 

25 ta generated by bit-by-bit combination of the master key 
and disc ID in a hash function SHA-1 defined in FIPS 
180-1 to provide an output of 160 bits and taking only 
data of a necessary length from the 160-bit output for 
use as a disc-unique key, by placing the master key and 

30 disc ID in a hash function based on a block encryption 
function and using a result of the placement, or other- 
wise. 

[0135] Then, a title key unique to each record is gen- 
erated (as indicated at a reference 1104) at random or 

35 by a predetermined random-number generation in the 
cryptography unit 150, and recorded to the disc 1120. 
The disc 1120 has a data management file which has 
stored therein information on what title is formed from 
data and where the data is from, and can store the title 

40 key in the file. 

[0136] Next, a title-unique key is generated from the 
disc-unique key and title key. It can be generated in 
some ways, for example, by using the hash function 
SHA-1 or the hash function based on a block encryption 

45 function. 

[01 37] In the above, the disk-unique key is generated 
from the master key and disc ID and the title-unique key 
is generated from the disc-unique key and title key. How- 
ever, the title-unique key may be generated directly from 

50 the master key and disc ID without having to generate 
the disc-unique key or a key equivalent to the title- 
unique key may be generated from the master key and 
disc ID without using the title key. 
[0138] It should be reminded that in case one of the 

55 transmission formats defined in the above DTCP stand- 
ard for example is used, data is transmitted as MPEG- 
2 TS packets in some cases. For example, when a set 
top box (STB) having received a satellite broadcast 



13 



25 



EP 1 185 020 A1 



26 



transmits the broadcast to a recorder without using the 
DTCP transmission format, the STB should preferably 
transmit, also on the IEEE 1394 serial data bus, the 
MPEG-2 TS packets transmitted on the satellite broad- 
casting transmission path since data conversion is not 
required. 

[0139] The recorder/player 1100 receives to-be-re- 
corded content data in the form of TS packets, and the 
aforementioned TS processor 300 appends, to each TS 
packet, an ATS being a time at which the TS packet has 
been received. Note that as in the above, a block seed 
appended to block data may be composed of an ATS, 
copy control information and other information in com- 
bination. 

[0140] A number X (e.g., X = 32) of TS packets each 
having an ATS appended thereto are arranged side by 
side to form one block of block data (shown in the upper 
portion of FIG. 5). As shown in the lower portions of 
FIGS. 11 and 12, the first to fourth bytes in the leading 
portion of the block data supplied for encryption are sep- 
arated (in a selector 1 1 08) to output a block seed includ- 
ing an ATS of 32 bits. A block key being an encryption 
key for data in the block is generated (as indicated at a 
reference 1 1 07) from the block seed and the previously 
generated title-unique key. 

[0141] FIG. 14 shows an example of the block key 
generation. FIG. 14 shows two examples of generation 
of a 64-bit block key from a 32-bit block seed and 64-bit 
title-unique ley. 

[0142] In Example 1 shown in the upper half of FIG. 
14, there is used an encryption function whose key 
length is 64 bits and input and output are of 64 bits, re- 
spectively. A title-unique key is taken as a key to this 
encryption function, a combination of a block seed and 
32-bit constant is placed in the encryption function, and 
a result of the placement is taken as a block key. 
[0143] Example 2 uses a hash function SHA-1 de- 
fined in FIPS 180-1 . A combination of a title-unique key 
and block seed is placed in the hash function SHA-1, 
and an output of 160 bits is reduced to 64 bits by using 
for example only low-order 64 bits. The 64 bits are used 
as a block key. 

[0144] In the above, there have been described the 
examples of the block key generation in which the disk- 
unique key, title-unique key and block key are generat- 
ed. However, the block key may be generated from a 
masker key, disc ID, title key and block seed for each 
block without generating the disc-unique key and title- 
unique key. 

[0145] The block key, thus generated, is used to en- 
crypt the block data. As shown in the lower portions of 
FIGS. 11 and 12, the first to m-th bytes (m = 8 for exam- 
ple) in the leading portion of the block data including a 
block seed are separated (in the selector 1108) not to 
be encrypted, and the (m+1)th to the last bytes are en- 
crypted (as indicated at a reference 1109). Note that the 
m bytes not to be encrypted include the first to fourth 
bytes as a block seed. The (m+1)th and subsequent 



bytes of the block data, selected in the selector 1108, 
are encrypted (as indicated at a reference 1 1 09) accord- 
ing to an encryption algorithm preset in the cryptography 
unit 150. The encryption algorithm may be DES (Data 

5 Encryption Standard) defined in Fl PS 46-2 for example. 
[01 46] When the block length (input/output data size) 
in the encryption algorithm used is 8 bytes as in DES, 
the entire block data including the (m+1)th and subse- 
quent bytes with no fraction can be encrypted by taking 

10 X as 32 and m as a multiple of 8 for example. 

[01 47] Namely, in case a number X of TS packets are 
stored in one block, input/output data size of the encryp- 
tion algorithm is L bytes and n is an arbitrary natural 
number, determining X, m and L so that 1 92*X = m+n*L 

15 makes it unnecessary to process any fraction. 

[0148] The encrypted (m+1)th and subsequent bytes 
of the block data are combined with the unencrypted first 
to m-th bytes of the block data by a selector 1110, and 
stored as an encrypted content 1112 into the recording 

20 medium 1120. 

[0149] With the above operations, the content will be 
encrypted block by block with a block key generated 
from a block seed including ATS, and stored into the re- 
cording medium. As having previously been described, 

25 since ATS is a random data unique to a block, so the 
block key generated based on ATS set for each block is 
different from one another. That is, the encryption key 
is varied from one blockto another and thus can provide 
an enhanced data protection against cryptanalysis. Use 

30 of the block seed as encryption key generating data 
makes it unnecessary to store the encryption key for 
each block separately from data. Thus, no special stor- 
age area is required forthe encryption key, and the stor- 
age area of the recording medium can effectively be 

35 saved. Since the block seed is data which can be written 
and read along with content data, so it is possible to omit 
the operation of writing or reading the encryption key 
generating data during data write or read, which is dif- 
ferent from the conventional system in which the encryp- 

40 tion key has to be stored in an area other than the data 
area. Namely, information recording and playback can 
be done with a higher efficiency. 
[01 50] The flow of operations effected in ATS append- 
ing by the TS processor 300 and data encryption by the 

45 cryptography unit 150 for recording data, will be de- 
scribed with reference to the flow chart in FIG. 13. In 
step S1 301 in FIG. 13, the recorder/player reads a mas- 
ter key stored in its own memory 180. 
[0151] In step S1302, the recorder/player checks if a 

50 disc ID as identification information is already recorded 
in the recording medium. When the disc ID is found re- 
corded there, the recorder/player reads the disc ID in 
step S1303. If the disc ID is not found recorded there, 
the recorder/player generates a disc ID at random or by 

55 a predetermined method, and records it to the disc (re- 
cording medium) in step S1 304. Next in step S1 305, the 
recorder/player generates a disc-unique key from a 
master key and disc ID. As having previously been de- 
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scribed, the disc-unique key is generated by the use of 
the hash function SHA-1 defined in FIPS 180-1 or the 
hash function based on a block encryption function, for 
example. 

[0152] The recorder/player goes to step S1 306 where 
it will generate a title key as a key unique to each record 
and record it to the disc. I n next step S 1 307, the record- 
er/player generates a title-unique key from the disc- 
unique key and title key by the use of the hash function 
SHA-1 or the hash function based on a block encryption 
function, for example. 

[0153] In step S1308, the recorder/player receives 
data resulted from to-be-recorded content data in the 
form of TS packets. In step S1309, the TS processor 
300 appends, to each TS packet, ATS which is informa- 
tion on a time at which the TS packet has been received. 
Alternatively, the TS processor 300 appends, to each 
TS packet, a combination of copy control information 
CCI, ATS and other information. Next in step S1 31 0, the 
recorder/player receives TS packets each having ATS 
appended thereto one after another, and judges if a 
number X = 32, for example, of TS packets forming one 
block have been received or an identification data indic- 
ative of the last TS packet has been received. When ei- 
ther of these conditions is fulfilled, the recorder/player 
goes to step S1 31 1 where it will arrange the number X 
of TS packets or TS packets down to the last one side 
by side to form one block of data. 
[0154] Next in step S1312, the cryptography unit 150 
generates a block key for use to encrypt data in the block 
from 32 bits (block seed including ATS) in the leading 
portion of the block data and the title-unique key having 
been generated in step S1307. 

[0155] In step S1313, the cryptography unit 150 en- 
crypts the block data formed in step S1311 with the block 
key. It should be reminded here that as having previous- 
ly been described, the cryptography unit 150 encrypts 
the (m+1)th to last bytes of the block data. The encryp- 
tion algorithm used here is for example the DSE (Data 
Encryption Standard) defined in FIPS 46-2. 
[0156] In step S1314, the recorder/player records the 
encrypted block data to the recording medium. In step 
S1315, it is judged whether all the data have been re- 
corded. If the result of judgment is that all the data have 
been recorded, the recorder/player exits the recording 
procedure. If not, the recorder/player goes back to step 
S1308 where it will process the remaining data. 

[Cryptography for data playback in a system with which 
recorded data has to be compatible] 

[0157] Next, decryption, for playback, of the encrypt- 
ed content recorded in the recording medium as having 
been described in the foregoing will be described below 
with reference to the block diagram in FIG. 15 and flow 
chart in FIG. 16. 

[0158] First, the description will be made with refer- 
ence to the block diagram in FIG. 1 5. A recorder/player 



1500 reads a disc ID 1502 from a disc 1520, and a mas- 
ter key 1 501 from its own memory. As apparent from the 
foregoing description of the data recording procedure, 
the disc ID is a disc-unique identifier recorded in a disc. 
5 Alternatively, when no disc ID is recorded, the recorder/ 
player 1 500 generates a disc ID and records it to a disc. 
The master key 1 501 is a private key stored in a licensed 
recorder/player. 

[0159] Next, the recorder/player 1500 generates a 
10 disc-unique key from the disc ID and master key (as in- 
dicated at a reference 1503) as follows. Data generated 
by a bit-by-bit combination of the master key and disc 
ID is placed in a hash function SHA-1 defined in FIPS 
1 80-1 for example, and only a necessary data length of 
15 an output of 160 bits resulted from calculation of the 
hash function is used as a disc-unique key. Alternatively, 
a result of the placement of the master key and disc ID 
in the hash function based on a block encryption func- 
tion is used as a disc-unique key. 
20 [0160] Next, the recorder/player 1500 reads, from the 
disc, a title key 1504 recorded correspondingly to data 
to be read, and generates a title-unique key 1505 from 
the title key 1 504 and disc-unique key. The title-unique 
key 1 505 may also be generated by the use of the hash 
25 function SHA-1 or the hash function based on a block 
encryption function. 

[0161] In above, the disk-unique key is generated 
from the master key and disc ID and the title-unique key 
is generated from the disc-unique key and title key. How- 
30 ever, the title-unique key may be generated directly from 
the master key and disc ID without having to generate 
any disc-unique key or a key equivalent to a title-unique 
key may be generated from the master key and disc ID 
without using any title key. 
35 [01 62] Next, the recorder/player 1 500 reads block da- 
ta one after another from an encrypted content 1507 
stored in the disc, separates a block seed forming four 
bytes in the leading portion of the block data by a selec- 
tor 1508, and generates a block key by the processing 
40 operation having also been made for generation of the 
title-unique key. 

[0163] The block key may be generated as having 
been described in the foregoing with reference to FIG. 
1 4. That is, a block key of 64 bits can be generated from 
45 a 32-bit block seed and 64-bit title-unique key. 

[0164] In the above, there have been described ex- 
amples of the block key generation in which the disk- 
unique key, title-unique key and block key are generat- 
ed. However, the block key may be generated from a 
50 masker key, disc ID, title key and a block seed for each 
block without generating the disc-unique key and title- 
unique key. 

[0165] When the block key is thus generated, the 
block data encrypted with a block key is decrypted (as 
55 indicated at a reference 1 509) and outputted as decrypt- 
ed data via a selector 1 51 0. Note that the decrypted data 
includes ATS appended to each of transport packets in- 
cluded in the transport stream and the stream is proc- 
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essed based on the ATS by the aforementioned TS 
processor 300. Thereafter, the data can be used to dis- 
play an image or play a music, for example. 
[0166] As in the above, a content encrypted in units 
of a block and recorded in the recording medium can be 
decrypted in units of a block for playback with a block 
key generated from a block seed including ATS. 
[0167] Next, the flow of operations effected in data de- 
cryption and playback will be described with reference 
to the flow chart shown in FIG. 1 6. In step S1 601 in FIG. 
1 6, the recorder/player reads a disc ID from the disc and 
a master key from its own memory. In step S1602, the 
disc ID and master key are used to generate a disc- 
unique key. 

[0168] Next in step S1 603, the recorder/player reads 
a title key of data to be read from the disc. I n step S1 604, 
the recorder/player generates a title-unique key from the 
title key and disc-unique key. Next in step S1605, the 
recorder/player reads encrypted block data from the 
disc. In step S1606, the recorder/player generates a 
block key from a 4-byte block seed in the leading portion 
of the block data and the title-unique key generated in 
step S1604. 

[0169] Next in step S1 607, encrypted data is decrypt- 
ed with the block key. Instep S1608, it is judged whether 
the recorder/player has read all the data. If it has read 
all the data, the recorder/player exits the decrypting pro- 
cedure. If not, the recorder/player goes back to step 
S1 605 where it will read the remaining data. 

[Data encryption for recording in a system with which 
recorded data have not to be compatible] 

[0170] Next, there will be described with reference to 
the block diagram in FIG. 17 and flow chart in FIG. 18 
the encrypting procedure for data recording in a system 
with which recorded data has not to be compatible, 
namely, a system in which a recording medium having 
data recorded therein by a recorder/player has not to be 
playable in another recorder/player, namely, a system 
in which recorded data can be read only by a recorder/ 
player having recorded the data to the recording medi- 
um. 

[0171] The description will be made with reference to 
the block diagram in FIG. 1 7 and following the sequence 
of operations in the flow chart in FIG. 1 8. 
[0172] In step S1801 in FIG. 18, a recorder/player 
1 700 (in FIG. 1 7) generates a device-unique key which 
is a key unique to the recorder/player itself. 
[0173] As shown in FIG. 17, the device-unique key is 
generated from any of LSI key, device key, medium key 
and a drive key or a combination of any of these keys. 
The LSI key is a key having been stored in the LSI during 
production of the LSI included in the cryptography unit 
1 50 (in FIG. 1 ). The device key is a key having been set 
correspondingly to a device, namely, a recorder/player, 
and stored in a memory element such as a flash mem- 
ory, EEPROM orthe like during production of the record- 



er/player. The medium key is a key set for a recording 
medium which stores a content and stored in the record- 
ing medium. The drive key is a key appended to the drive 
unit forthe recording medium such as a DVD orthe like. 

5 [0174] In this embodiment, the device-unique key is 
generated from any of LSI key, device key, medium key 
and drive key or a combination of any of these keys. 
[0175] The generation of the device-unique key from 
the LSI key and device key for example will be described 

10 with reference to FIG. 19 showing, by way of example, 
operations effected in a cryptography LSI 1900 being 
the cryptography unit 150 in FIG. 1 formed in the form 
of an LSI for example. 

[0176] The cryptography LSI 1900 includes an LSI 

15 key memory 1901 which stores an LSI key common to 
a plurality of cryptography LSIs (therefore, common to 
a plurality of recorder/players). More particularly, the 
same key is stored in the LSIs in one production lot. A 
common LSI key may be stored in all the cryptography 

20 LSIs, or a common LSI key may be stored in each group 
of some cryptography LSIs. To how many LSIs the com- 
mon LSI key should be common may be determined 
based on the manufacturing cost of the cryptography 
LSI for example. 

25 [0177] The cryptography LSI 1900 has a key genera- 
tor which reads LSI key from the key memory 1901 while 
reading a device key 1 91 0 from a ROM in the recorder/ 
player for example as an external memory element of 
the cryptography LSI 1900 via a bus, and generates a 

30 device-unique key by applying a key generation function 
to the LSI key and device key. 

[0178] Note that as a key generation function, there 
may be used a one-way function with which the device- 
unique key can easily be calculated from the LSI and 

35 device keys but the LSI and device keys cannot be cal- 
culated. More specifically, with a combination of the LSI 
and device keys being placed in the one-way function 
such as a hash function SHA-1 defined in FIPS 180-1 
for example, a device-unique key generator 1902 cal- 

40 culates the hash function to generate a device-unique 
key. The device-unique key may be generated by the 
use of a one-way function using DES defined in FIPS 
46-2 orTriple-DES defined in FIPS 46-3 and encrypting 
the device key with the LSI key. 

45 [0179] A block key is generated from the device- 
unique key thus generated and a block seed set as ad- 
ditional data to the content data, encryption or decryp- 
tion is effected with the block key th us generated to write 
or read an encrypted content 1 906 to or from a recording 

50 medium 1920. 

[0180] For the content encryption and decryption, 
there may be used the DES (Data Encryption Standard) 
defined in FIPS 46-2 orthe like. 

[0181] FIG. 19 shows an example that a device- 
55 unique key is generated from an LSI key and device key. 
However, in case a medium key is assigned as a fixed 
value to a recording medium or in case a drive key is 
assigned as a fixed value to a drive for the recording 
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medium, the medium key and drive ley may be used for 
generation of the device-unique key 
[0182] FIG. 20 shows an example of the generation 
of a device-unique key from all the keys including the 
medium key and drive key in addition to the LSI key and 
device key. In FIG. 20, there is illustrated an example of 
the generation of the device-unique key by the DIM (da- 
ta integrity mechanism) defined in ISO/I EC 9797. 
[0183] An encryption unit 2001 encrypts the LSI key 
with the device key, and outputs the encrypted LSI key 
to an arithmetic unit 2004. The arithmetic unit 2004 
makes an exclusive-O R operation of the output from the 
encryption unit 2001 and medium key, and supplies a 
result of the exclusive-OR operation to an encryption 
unit 2002. The encryption unit 2002 encrypts the output 
of the arithmetic unit 2004 with the LSI key, and outputs 
the data to an arithmetic unit 2005. The arithmetic unit 
2005 makes an exclusive-OR operation of the output of 
the encryption unit 2002 and drive key, and outputs the 
data to an encryption unit 2003. The encryption unit 
2003 encrypts the output of the arithmetic unit 2005 with 
the LSI key, and outputs a result of the encryption as a 
device-unique key. 

[0184] The data recording procedure will be continu- 
ously described with reference to FIG. 1 8 again. In step 
S1801, a device-unique key is generated from any of 
the LSI key, device key, medium key and drive key or a 
combination of any of these key. 
[0185] In step S1802, the recorder/player receives a 
to-be-recorded encoded content data in the form of TS 
packets. In step S1803, theTS processor 300 appends, 
to each TS packet, ATS being a time at which each of 
theTS packets has been received. Alternatively, theTS 
processor 300 appends, to each TS packet, a combina- 
tion of copy control information CCI, ATS and other in- 
formation. Next in step S1 804, theTS packets each hav- 
ing ATS appended thereto are received one after anoth- 
er, and it is judged whether a number X (e.g., X = 32) of 
TS packets forming one block have been received or an 
identification data indicative of the last TS packet has 
been received. If any of the above conditions is found 
fulfilled, the recorder/player goes to step S1805 where 
it will arrange the number X of TS packets orTS packets 
down to the last one side by side to form one block of 
data. 

[0186] Next, in step S1806, the cryptography unit 150 
generates a block key being a key to encrypt the block 
data from 32 bits (block seed including ATS) in the lead- 
ing portion of the block data and the device-unique key 
having been generated in step S1801 . 
[0187] In step S1 807, the block data formed using the 
block key in step S1 805 is encrypted. Note that as hav- 
ing previously been described, it is the (m+1)th byte to 
the last byte of the block data that are encrypted. The 
encryption algorithm used forthis purpose is DES (Data 
Encryption Standard) defined in Fl PS 46-2 for example. 
[0188] In step S1 808, the recorder/player records the 
encrypted block data to the recording medium. In step 



S1 809, it is judged whether or not all the data have been 
recorded. If all the data have been recorded, the record- 
er/player exits the recording procedure. If all the data 
have not yet been recorded, the recorder/player goes 
5 back to step S1 802 where it will process the remaining 
data. 

[Data encryption for playback in a system with which 
recorded data has not to be compatible] 

[0189] Next, playback or reading of the data thus re- 
corded will be described with reference to the block di- 
agram in FIG. 21 and flow chart in FIG. 22. 
[0190] The description will be made with reference to 
the block diagram in FIG. 21 and following the sequence 
of operations in the flow chart in FIG. 22. 
[0191] First in step S2201 in FIG. 22, a recorder/play- 
er 21 00 (see FIG. 21 ) generates a device key unique to 
itself. 

[0192] As shown in FIG. 21 , the device-unique key is 
generated from any of LSI key, device key, medium key 
and drive key or a combination of any of these keys (as 
indicated at a reference 21 01 ). As mentioned in the fore- 
going, the LSI key is a key having been stored in the LSI 
during production of the LSI included in the cryptogra- 
phy unit 150 (in FIGS. 1 and 2), the device key is a key 
having been set correspondingly to a device, namely, a 
recorder/player, and stored in a memory element such 
as a flash memory, EEPROM or the like during produc- 
tion of the recorder/player, the medium key is a key set 
for a recording medium which stores a content and 
stored in the recording medium, and the drive key is a 
key appended to the drive unit for the recording medium 
such as a DVD or the like. 

[0193] Next in step S2202, the recorder/player reads 
an encrypted block data from the disc. In S2203, the re- 
corder/player generates a block key from a block seed 
of 4 bytes in the leading portion of the block data and 
the device-unique key having been generated in step 
S2201 (as indicated at a reference 2102 in FIG. 21). 
[0194] Next in step S2204, the recorder/player de- 
crypts the block data having been encrypted with the 
block key (as indicated at a reference 2105 in FIG. 21), 
judges in step S2205 whether or not all the data have 
been read. If all the data have been read, the recorder/ 
player exits the reading procedure. If not, the recorder/ 
player goes back to step S2202 where it will read the 
remaining data. 

[0195] Note that also in this playback procedure, the 
first to fourth bytes of a block seed in the leading portion 
of the block data in an encrypted content 21 03 stored in 
a recording medium 2120 are separated by a selector 
21 04 while the first to m-th bytes yet to be encrypted are 
not decrypted, but the bytes are combined together in a 
selector21 06 and outputted from the latter. The decrypt- 
ed data includes ATS appended to each of packets and 
indicating a time at when it has been inputted, and thus 
can normally be played back owing to the processing by 
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the aforementioned TS processor. 
[0196] As in the above, according to the present in- 
vention, a content is encrypted with a block key varying 
depending upon an ATS which also varies with a recep- 
tion time of the leading TS packet in the block data. So, 
even if an encrypting block key for a certain content has 
leaked to any unlicensed user, other contents can be 
protected without being influenced by the leakage. In 
case a single encryption key is used for encryption of all 
contents as in the conventional system, the encryption 
with a fixed data key will possible result as follows. 
Namely, if an unlicensed user trying to illegally copy the 
contents has acquired a combination of an unencrypted 
or plain content and a content derived from encryption 
of that content with a data key, it is likely that the data 
key can be analyzed by a so-called linear or differential 
attack (to lay open the contents), whereby all contents 
having been encrypted with the data key can be decrypt- 
ed for illegal copying. According to the present inven- 
tion, however, since the encryption key is different from 
one block to another, such an illegal copying is almost 
impossible. 

[0197] According to the present invention, since the 
data amount encrypted with one encryption key is only 
one block which includes an extremely small amount of 
data, so it is very difficult to use the so-called linear or 
differential attack for acquisition of the key with which 
the data has been encrypted. 

[0198] Further, according to the present invention, 
since an encryption key is generated based on an ATS 
appended as additional information to the main data, so 
it has not to newly be recorded in a sector header etc. 
of a data sector of a recording medium even in case it 
is varied from one block to another. Thus, no extra re- 
cording area is required and it is not necessary to read 
and write an encryption key for each block for write and 
read of data. 

[Data encryption for recording in a system in which the 
player restriction can be set] 

[0199] The aforementioned construction of the re- 
corder/player according to the present invention is such 
that a block key can be generated from a master key 
and recorded data can be read by recorder/players hav- 
ing a common master key. However, it is desirable as 
the case may be that only a recorder/player having re- 
corded a specific data should be able to read or play 
backthe data. Such a player restriction will be described 
below. 

[0200] There will be described a system in which the 
recording medium 1 95 is removably set in the recorder/ 
player having been described in the foregoing with ref- 
erence to FIGS. 1 and 2 and can also be used in another 
recorder/player. That is, when data is recorded to the 
recording medium 1 95, it is settable whether or not the 
recording medium having the data recorded therein can 
be played in another recorder/player. 



[0201] The data encryption for recording in such a 
system will be described with reference to the block di- 
agrams shown in FIGS. 23 and 24 and flow chart shown 
in FIG. 25. The recording medium used here is an optical 
5 disc. In this embodiment, a disc ID as information unique 
to a recording medium is caused to act on a data en- 
cryption key in order to prevent bit-by-bit copying of data 
in the recording medium. 

[0202] Data encryption by the cryptography unit 150 
10 will be outlined below with reference to the block dia- 
grams in FIGS. 23 and 24. 

[0203] A recorder/player 2300 reads a master key 
2301 , device ID 2331 for identification of the recorder/ 
player, and a device-unique key 2332 from its own mem- 

15 ory 1 80 (see FIGS. 1 and 2). The master key 2301 is a 
private key stored in a licensed recorder/player and 
which is common to a plurality of recorder/players, 
namely, to an entire system. The device ID is an identi- 
fier for-the recorder/player 2300, such as a serial 

20 number or the like having been prestored in the record- 
er/player. The device-unique key is a private key unique 
to the recorder/player 2300 and preset to be different 
from one recorder/player to another. These keys have 
been prestored in the recorder/player 2300. 

25 [0204] The recorder/player 2300 checks that the disc 
ID 2303 as identification information has already been 
recorded in a recording medium 2320 which is an optical 
disc for example. If the disc ID 2303 has been so record- 
ed, the recorder/player 2300 reads the disc ID 2303 (as 

30 in FIG. 23). If not, the cryptography unit 150 will generate 
a disc ID 2401 at random or by a predetermined random 
number generation method, and record it to the optical 
disc (as in FIG. 24). Only one disc ID 2303 has to be 
available to each disc, and so the disc ID may be stored 

35 in a lead-in area or the like of the optical disc. 

[0205] Next, the recorder/player 2300 generates a 
disc-unique key from the master key and disc ID (as in- 
dicated at a reference 2302). More particularly, the disc- 
unique key is generated as will be described below. 

40 Namely, as shown in FIG. 26, a result from placement 
of the master key and disc ID in a hash function based 
on a block encryption function is used as a device- 
unique key (method 1). Alternatively, a necessary data 
length of an output of 1 60 bits resulted from placement, 

45 in a hash function SHA-1 defined in FIPS 180-1 , of data 
generated by bit-by-bit combination of the master key 
and disc ID is used as a disc-unique key (method 2). 
[0206] Next, a title key being a unique key for each 
record is generated at random or by a predetermined 

50 random number generation method for example by the 
cryptography unit 150 (as indicated at a reference 
2304), and recorded to the disc 2320. 
[0207] Further, a flag indicating which the title (data) 
is a data that can be played back only by the recorder/ 

55 player having recorded the data (when the player re- 
striction is set) or a data that can be played back also in 
another recorder/player (when the player restriction is 
not set), that is, a player restriction flag, is set (as indi- 
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cated at a reference 2333) and recorded to the disc 2320 
(as indicated at a reference 2335). Moreover, a device 
ID 2334 as device identification information is taken out 
(as indicated at a reference 2331) and recorded to the 
disc 2320 (as indicated at a reference 2334). 
[0208] The disc has provided therein a data manage- 
ment file having stored therein information on what title 
is formed from data and where the data is from, and 
which can store a title key 2305, player restriction flag 
2335 and device ID 2334. 

[0209] Next, a title-unique key is generated from ei- 
ther a combination of the disc-unique key, title key and 
device ID or a combination of the disc-unique key, title 
key and device-unique key. 

[021 0] Namely, in case the player restriction is not set, 
the title-unique key is generated from the disc-unique 
key, title key and device ID. On the other hand, in case 
the player restriction is set, the title-unique key is gen- 
erated from the disc-unique key, title key an device- 
unique key. 

[021 1 ] More particularly, the title-unique key is gener- 
ated is generated as in either Example 1 or Example 2 
shown in FIG. 28. In Example 1 , a title key, disc-unique 
key and a device ID (when the player restriction is not 
set) or a device-unique key (when the player restriction 
is set) are placed in a hash function based on a block 
encryption function, and a result of the placement is 
used as a title-unique key. In Example 2, data generated 
by bit-by-bit combination of a master key, disc ID and a 
device ID (when the player restriction is not set) or a 
device-unique key (when the player restriction is set) is 
placed in a hash function SHA-1 defined in FIPS 180-1 , 
and only a necessary data length of an output of 160 
bits resulted from the placement is used as a title-unique 
key. 

[0212] In the above, a disc-unique key is generated 
from a master key and disc ID, and then a title-unique 
key is generated from the disc-unique key, title key and 
device ID or from the title key and device-unique key. 
Note however that the title-unique key may be generat- 
ed directly from the master key, disc ID, title key and 
device ID or device-unique key without using the disc- 
unique key or a key equivalent to the title-unique key 
may be generated from the master key, disc ID and a 
device ID (when the player restriction is not set) or a 
device-unique key (when the player restriction is set) 
without using the title key. 

[0213] For example, in case one of the transmission 
formats defined in the aforementioned DTCP standard 
is used, data is transmitted in the form of MPEG-2 TS 
packets in some cases. When a STB (set top box), for 
example, having received a satellite broadcast trans- 
mits the broadcast to a recorder under the DTCP stand- 
ard, it is desirable because there is no necessity of data 
conversion that the STB should transmit, on an IEEE 
1394 serial bus as well, MPEG-2 TS packets having 
been transmitted over a satellite broadcasting commu- 
nication path. 



[0214] The recorder/player 2300 receives a to-be-re- 
corded content data in the form of the TS packets, and 
theTS processor 300 appends, to each of theTS pack- 
ets, ATS which is information indicative of a time at 

5 which the TS packet has been received. Note that a 
combination of ATS, copy control information and other 
information may be appended as a block seed being ad- 
ditional information unique to the block data, as having 
previously been described. 

10 [0215] A number X (e.g., X = 32) of TS packets each 
having ATS appended thereto are arranged side by side 
to form a block of data (block data) as shown in the upper 
portion of FIG. 5, and a block key intended for encryption 
of data in the block is generated from a block seed in- 

15 eluding a 32-bit ATS derived from separation of the first 
to fourth bytes in the leading portion of the block data 
supplied as encrypted data (in the selector 2308) and 
the title-unique key previously generated (as indicated 
at a reference 2307) as shown in the lower portions of 

20 FIGS. 23 and 24. The block key may be generated by 
the method having previously been described with ref- 
erence to FIG. 14. 

[0216] In the above, examples of the generation of 
disc-unique key, title-unique key and block key have 

25 been described. However, it should be noted that the 
block key may be generated from a master key, disc ID, 
title key, block seed and a device ID (when the player 
restriction is not set) or a device-unique key (when play- 
er ion is set) without generating any disc-unique key and 

30 title-unique key. 

[0217] The block key, thus generated, is used to en- 
crypt the block data. As shown in the lower portions of 
FIGS. 23 and 24, the first to m-th bytes (e.g., m = 8) in 
the leading portion of the block data including a block 

35 seed are separated (in the selector 2308) not to be en- 
crypted, and the (m+1)th to the last bytes are encrypted 
(as indicated at a reference 2309). Note that them bytes 
not to be encrypted include the first to fourth bytes as a 
block seed. The (m+1)th and subsequent bytes of the 

40 block data, separated by the selector 2308, are encrypt- 
ed (as indicated at a reference 2309) according to an 
encryption algorithm preset in the cryptography unit 
150. The encryption algorithm may be DES (Data En- 
cryption Standard) defined in FIPS 46-2 for example. 

45 [0218] When the block length (input/output data size) 
in the encryption algorithm used is 8 bytes as in DES, 
the entire block data including the (m+1)th and subse- 
quent bytes with no fraction can be encrypted by taking 
X as 32 and m as a multiple of 8 for example. 

50 [0219] Namely, in case a number X of TS packets is 
stored in one block, input/output data size of the encryp- 
tion algorithm is L bytes and n is an arbitrary natural 
number, any fraction has not to be processed by deter- 
mining X, m and L so that 1 92*X = m+n*L. 

55 [0220] The encrypted (m+1)th and subsequent bytes 
of the block data are combined with the unencrypted first 
to m-th bytes of the block data by a selector 231 0, and 
stored as an encrypted content 2312 into the recording 
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medium 1120. 

[0221 ] With the above operations, the content will be 
encrypted block by block with a block key generated 
from a block seed including ATS, and stored into the re- 
cording medium. The block key is generated from a de- 
vice ID when the player restriction is not set, or from a 
device-unique key when the player restriction is set. In 
case the player restriction is set, these encrypted data 
can be read or played back only by a device having re- 
corded the data. 

[0222] More particularly, when the player restriction is 
not set, a block key being a key for use to encrypt block 
data is generated from data including a device ID and 
the device ID is stored into the recording medium. 
Therefore, a player going to play the recording medium 
can acquire the device ID from the recording medium 
set therein and thus generate a similar block key. Thus 
the block data can be decrypted. However, in case the 
player restriction is set, a block key being a key for use 
to encrypt block data is generated from data including 
a device-unique key. Since this device-unique key is a 
private key which varies from one device to another, so 
it cannot be acquired by the other device. In case block 
data is encrypted for storage into a recording medium, 
data write is not made to a recording medium having the 
device-unique key stored therein. Therefore, since the 
same device-unique key cannot be acquired even with 
a recording medium having encrypted block data stored 
therein, set in the other player, so any decryption key for 
decryption of the block data cannot be generated and 
thus the block data cannot be decrypted for playback. 
Note that the playback operations will further be de- 
scribed later. 

[0223] Next, there will be described with reference to 
FIG. 25 a flow of operations effected in appending ATS 
in the TS processor 300 and a flow of operations effect- 
ed in encryption by the cryptography unit 150, when re- 
cording data. In step S2501 in FIG. 25, the recorder/ 
player reads a master key, device ID which identifies the 
recorder/player and a device-unique key stored in its 
own memory 180. 

[0224] In step S2502, the recorder/player checks 
whether the disc ID as identification information has al- 
ready been recorded in the recording medium. If it is 
found so recorded, the recorder/player reads the disc 
ID in step S2503. If not, the recorder/player generates 
a disc ID at random or by a predetermined method, and 
records it in the disc in step S2504. Next in step S2505, 
the recorder/player generates a disc-unique key from 
the master key and disc ID. A disc-unique key is gener- 
ated by the use of the function SHA-1 defined in FIPS 
180-1 or the hash function based on a block encryption 
function, for example, as in the above. 
[0225] The recorder/player goes to step S2506 where 
it will extract a title key unique to each record, player 
restriction flag and a device ID being identification infor- 
mation for the device, and record them to the disc. Next 
in step S2507, the recorder/player generates a title- 



unique key from the disc-unique key, title key and a de- 
vice ID (when the player restriction is not set) or a de- 
vice-unique key (when the player restriction is set). 
[0226] FIG. 27 shows the flow of operations effected 
5 in generation of a title-unique key in detail. In step 
S2701, the cryptography unit 150 judges if the player 
restriction should be set, based on instructive data en- 
tered by the user of the recorder/player or use-limiting 
information appended to content. 
[0227] If the judgment made in step S2701 is "NO", 
namely, if the player restriction is not set, the recorder/ 
player goes to step S2702 where it will generate a title- 
unique key from a disc-unique key, title key and device 
ID. 

[0228] If the judgment made in step S2701 is "YES", 
namely, if the player restriction is set, the recorder/play- 
er goes to step S2703 where it will generate a title- 
unique key from a disc-unique key, title key and device- 
unique key, by the use of the hash function SHA-1 or 
the hash function based on a block encryption function. 
[0229] In step S2508, the recorder/player receives to- 
be-encrypted data of a to-be-recorded content data in 
the form of TS packets. In step S2509, theTS processor 
300 will append, to each of the TS packets, ATS being 
information indicative of a time at which the packet has 
been received. Alternatively, the TS processor 300 will 
append, to each TS packet, a combination of copy con- 
trol information CCI, ATS and other information. Next in 
step S2510, the recorder/player receives TS packets 
each having ATS appended thereto one after another, 
and judges whether a number X (e.g. , X = 32) of the TS 
packets forming one block have been received or iden- 
tification data indicating the last packet has been re- 
ceived. When either of the above conditions is fulfilled, 
the recorder/player goes to step S2511 where it will ar- 
range the number X of TS packets or TS packets down 
to the last one side by side to form one block of data. 
[0230] Next in step S251 2, the cryptography unit 1 50 
generates a block key being a key for use to encrypt the 
data in the above block from 32 bits (block seed includ- 
ing ATS) in the leading portion of the block data and the 
title-unique key having been generated in step S2507. 
[0231] In step S2513, the block data formed in step 
S2511 is encrypted with the block key. As having previ- 
ously been described, the (m+1)th to the last bytes in 
the block data are subjected to the encryption. The en- 
cryption algorithm is DES (Data Encryption Standard) 
defined in FIPS 46-2 for example. 
[0232] In step S2514, the encrypted block data is re- 
corded to a recording medium. In step S2515, it is 
judged whether or not all the data have been recorded 
to the recording medium. When all the data have been 
recorded, the recorder/player exits the recording proce- 
dure. If not, the recorder/player goes back to step S2508 
where it will process the remaining data. 
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[Decryption are playback of recorded data in a system 
in which the player restriction can be set] 

[0233] Next, there will be described with reference to 
the block diagram in FIG. 29 and flow chart in FIG. 30 
the operations effected for decryption, for playback, of 
encrypted content recorded in a recording medium as 
having been described in the foregoing. 
[0234] First, description will be made with reference 
to the block diagram in FIG. 29. A recorder/player 2900 
reads a disc ID 2902 from a disc 2920, and a master 
key 2901 , device ID 2931 and device-unique key 2932 
from its own memory. As apparent from the previous de- 
scription of the recording procedure, the disc ID is an 
identifier unique to a disc, recorded in the disc. If not 
recorded in the disc, it is generated by the recorder/play- 
er and recorded in the disc. The master key 2901 is a 
private key stored in the licensed recorder/player 2900, 
the device ID is an identifier unique to the recorder/play- 
er 2900 and the device-unique key is a private key 
unique to the recorder/player. 

[0235] Next, the recorder/player 2900 generates a 
disc-unique key from the disc ID and master key (as in- 
dicated at a reference 2903). The disc-unique key is 
generated by placing data generated by bit-by-bit com- 
bination of the master key and disc ID in a hash function 
SHA-1 defined in FIPS 180-1 forexampleand using only 
necessary data length of a 1 60-bit output resulted from 
the placement, or the disc-unique key is generated us- 
ing a result from placement of the master key and disc 
ID in a hash function based on a block encryption func- 
tion. 

[0236] Next, the recorder/player reads a title key 2905 
recorded correspondingly to data to be read from the 
disc, and further a device ID 2935 for a recorder/player 
having recorded the data, and a player restriction flag 
2933 having been set correspondingly to the data. If 
player restriction information indicated by the player re- 
striction flag 2933 thus read is "Player restriction is set" 
and "Device ID 2934 read from the recording medium 
coincides with a device ID 2931 of the player itself" or 
"Player restriction is not set", the data can be played 
back. If the player restriction information indicated by 
the player restriction flag 2933 is "Player restriction is 
set" and "Device ID 2934 read from the recording me- 
dium does not coincide with a device ID 2931 oftheplay- 
er itself, the data cannot be played back. 
[0237] The reason why the data cannot be played 
back is that a block key for decryption of the data cannot 
be generated since the data has been encrypted with a 
block key generated from a device-unique key for a re- 
corder/player having recorded the data and the record- 
er/players other than the recorder/player having record- 
ed the data have not the same device-unique key. 
[0238] In case the data can be played back, a title- 
unique key is generated from a combination of the disc- 
unique key, title key and device ID or a combination of 
the disc-unique key, title key and device-unique key. 



[0239] That is, when the player restriction is not set, 
the title-unique key is generated from the disc-unique 
key, title key, device ID and title-unique key. When the 
player restriction is set, the title-unique key is generated 

5 from the disc-unique key, title key and a device-unique 
key of the player itself. For generation of the title-unique 
key, the hash function SHA-1 or hash function based on 
a block encryption function can be used. 
[0240] In the above, the disc-unique key is generated 

10 from the master key and disc ID and the title-unique key 
is generated from a combination of the disc-unique key, 
title key and device ID or a combination of the title key 
and device-unique key. However, the title-unique key 
may be generated directly from the master key, disc ID, 

15 title key and device ID or device-unique key without us- 
ing any disc-unique key or a key equivalent to the title- 
unique key may be generated from the master key, disc 
ID and device ID (when the player restriction is not set) 
or device-unique key (the player restriction is set) with- 

20 out using any title key. 

[0241] Next, the recorder/player will read block data 
one after another from encrypted data 2912 stored in 
the disc, separate a block seed forming four bytes in the 
leading portion of the block data in a selector 291 0 and 

25 generate a block key from the title-unique key and block 
seed. 

[0242] The block key may be generated as having 
previously been described in the foregoing with refer- 
ence to FIG. 14. That is, a 64-bit block key can be gen- 
30 erated from a 32-bit block seed and 64-bit title-unique 
key. 

[0243] In the above, examples of generation of the 
disc-unique key, title-unique key and block key have 
been described. Note however that a block key may be 

35 generated, for each block, from a master key, disc ID, 
title key, block seed and a device ID (when the player 
restriction is not set) or a device-unique key (when the 
player restriction is set) without having to generate any 
disc-unique key and title-unique key. 

40 [0244] The encrypted block data is decrypted with the 
block key thus generated, (as indicated at a reference 
2909) and outputted as decrypted data via a selector 
2908. Note that the decrypted data includes ATS ap- 
pended to each of transport packets included in the 

45 transport stream and the stream is processed based on 
the ATS in the aforementioned TS processor 300. 
Thereafter, the data can be used to display an image or 
play a music, for example. 

[0245] Thus, the content encrypted in units of a block 
50 and stored in the recording medium can be decrypted, 
for playback, with the block key generated from the 
block seed including ATS in units of a block. 
[0246] Next, a flow of operations effected in data de- 
cryption and playback will be described with reference 
55 to the flow chart shown in FIG. 30. In step S3001 in FIG. 
30, the recorder/player reads a disc ID from the disc and 
a master key, device ID and device-unique key from its 
own memory. In step S3002, the recorder/player gener- 
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ates a disc-unique key from the disc ID and master key. 
[0247] Next in step S3003, the recorder/player reads 
a title key for data to be read from the disc, a device ID 
for the recorder/player having recorded the data, and a 
player restriction flag set correspondingly to the data. 
[0248] Next in step S3004, the recorder/player judges 
whether the data to be read can be played back. The 
judging procedure is as shown in FIG. 31 . In step S31 01 
in FIG. 31 , it is judged whether player restriction infor- 
mation indicated by the read player restriction flag is 
"Player restriction is set". If so, the recorder/player judg- 
es in step S31 02 whether "Device ID read from the re- 
cording medium coincides with a device-unique ID of the 
player itself". If so, the recorder/player provides a judg- 
ment that the data can be played back. Also, when the 
result of judgment in step S3101 is that "Player restric- 
tion is not set", the recorder/player will judge that the 
data can be played back. If the player restriction infor- 
mation indicated by the read player restriction flag is 
"Player restriction is set" and "Device ID read from the 
recording medium does not coincide with a device ID of 
the player itself", the recorder/player will judge that the 
data cannot be played back. 

[0249] Next in step S3005, the recorder/player will 
generate a title-unique key. The flow of operations ef- 
fected in generation of the title-unique key will be de- 
scribed in detail with reference to FIG. 32. In step S3201 , 
the cryptography unit 1 50 judges whether the player re- 
striction should be set or not, based on the player re- 
striction flag read from the disc. 

[0250] If the result of judgement made in step S3201 
is "NO", that is, if the result of judgment is that the player 
restriction should not be set, the recorder/player goes 
to step S3202 where it will generate a title-unique key 
from a disc-unique key, title key and device ID. 
[0251] If the judgment made in step S3201 is "YES", 
that is, if is judged that the player restriction should be 
set, the recorder/player goes to step S3203 where it will 
generate a title-unique key from a disc-unique key, title 
key and a device-unique key of the player itself. The ti- 
tle-unique key is generated by the use of the hash func- 
tion SHA-1 or the hash function based on a block en- 
cryption function. 

[0252] Next in step S3006, the recorder/player reads 
a block seed encrypted and stored in the disc. In step 
S3007, the recorder/player generates a block key from 
a block seed including four bytes in the leading portion 
of the block data and the tile-unique key generated in 
step S3005. 

[0253] Next in step S3008, the recorder/player de- 
crypts the block data encrypted with a block key, and 
judges in step S3009 whether all the data have been 
read. If all the data have been read, the recorder/player 
exits the procedure. If not, the recorder/player goes 
backto step S3006 where it will read the remaining data. 
[0254] As in the above, when the player restriction is 
not set, the recorder/player can generate a block key 
from a device ID. In case the player restriction is set, the 



recorder/player can generate a block key from a device- 
unique key. In any of these cases, the recorder/player 
can encrypt a content in units of a block and record the 
encrypted data to the recording medium. For playback 

5 of data from the recording medium, data having been 
encrypted with the device-unique key can be played 
back only by a device having recorded the data. In case 
the player restriction is not set, any recorder/player other 
than the device having recorded the data can generate 

10 a block key from a device ID recorded in the disc, and 
thus decrypt and play back the data. 

[Copy control in data recording] 

15 [0255] Now, to protect the profit of the copyrighter of 
a content, a licensed device has to control copying of 
the content. 

[0256] That is to say, for recording a content to a re- 
cording medium, it is necessary to check whether the 
20 content may be copied or not and record only a data 
which may be copied. Also, for playing back a content 
from a recording medium and outputting the data, the 
content has to be prevented from illegally being copied 
subsequently. 

25 [0257] The operations of the recorder/player shown 
in FIGS. 1 and 2 for recording or playing back such a 
content while controlling copying of the content will be 
described with reference to the flow charts shown in 
FIGS. 33 and 34. 

30 [0258] First, for recording an external content of dig- 
ital signals to a recording medium, recording operations 
are effected as in the flow chart shown in FIG. 33A. The 
operations in FIG. 33Awill be described herebelow con- 
cerning the recorder/player 100 shown in FIG. 1 as an 

35 example. The input/output l/F 1 20 receives a content of 
digital signals (digital content) via the IEEE 1394 serial 
bus or the like in step S3301 and the recorder/player 
goes to step S3302. 

[0259] In step S3302, the input/output l/F 1 20 judges 
40 whetherthe supplied digital content can be copied. That 
is, in case the content received by the input/output l/F 
120 has not been encrypted (for example, plain or un- 
encrypted content is supplied to the input/output l/F 1 20 
without applying the aforementioned DTCP standard), 
45 there will be made a judgment that the content can be 
copied. 

[0260] Assume here that the recorder/player 1 00 is a 
device conforming to the DTCP standard and records 
data according to the DTCP standard. The DTCP stand- 
so ard defines 2-bit EMI (encryption mode indicator) as 
copy control information. When EMI is "00B" (B indi- 
cates that a preceding value is a binary number), it 
means that the content can be freely copied (copy-free- 
ly). When EMI is "01 B", it means that the content cannot 
55 be copied more than a predetermined limit (no-more- 
copies). Further, when EMI is "10B", it means that the 
content can be copied once (copy-one-generation). 
When EMI is "1 1 B", it means that the content is prohib- 
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ited from being copied (copy-never). 
[0261] Signals supplied to the input/output l/F 120 of 
the recorder/player 100 include EMI. When the EMI 
means "copy-free" or "copy-one-generation", it will be 
judged that the content can be copied. On the other 5 
hand, when EMI means "no-more-copies" or "copy-nev- 
er", it will be judged that the content cannot be copied. 
[0262] If the result of judgment in step S3302 is that 
the content cannot be copied, the recorder/player 100 
skips oversteps S3303 to S3305 and exits the recording 10 
procedure. Therefore, in this case, the content will not 
be copied to the recording medium 1 95. 
[0263] If the result of judgment in step S3302 is that 
the content can be copied, the recorder/player 1 00 goes 
to step S3303. Subsequently, in steps S3303 to S3305, 15 
the recorder/player 100 will make similar operations to 
those in steps S302, S303 and S304 in FIG. 3A. That 
is, the TS processor 300 will append ATS to each TS 
packet included in a transport stream, the cryptography 
unit 150 will encrypt data, and the encrypted data from 20 
the cryptography unit 150 is recorded to the recording 
medium 1 95. Here, the recorder/player exits the record- 
ing procedure. 

[0264] Note that EMI is included in the digital signals 
suppliedto the input/output l/F 120. In case a digital con- 25 
tent is recorded to the recording medium 195, EMI or 
information indicative of a copy control status similar to 
EMI (embedded CCI defined in the DTCP or the like for 
example) is recorded along with the digital content. 
[0265] Generally, the information indicating "copy- 30 
one-generation" is converted to "no-more-copies" and 
recorded to prohibit more copies than a predetermined 
limit. 

[0266] The recorder/player according to the present 
invention records copy control information such as EMI, 35 
embedded CCI, etc. as appended to TS packets. That 
is, as in Examples 2 and 3 in FIG. 10, 32 bits including 
24 to 30 bits of ATS and copy control information are 
appended to each TS packet as shown in FIG. 5. 
[0267] For recording an external content of analog 40 
signals to a recording medium, a recording procedure 
is effected as intheflowchartin FIG. 33B. The recording 
procedure shown in FIG. 33B will be described herebe- 
low. A content of analog signals (analog content) is sup- 
plied to the input/output l/F 1 40 in step S331 1 . Then the 45 
recorder/player goes to step S3312 where it will judge 
whether the received analog content can be copied. 
[0268] In step S3312, the judgment is done based on 
whether or not the signals received by the input/output 
l/F 1 40 include a Macrovision signal and CGMS-A (copy 50 
generation management system-analog) signal. When 
recorded in a VHS video cassette tape, the Macrovision 
signal will be a noise. When this Macrovision signal is 
included in signals received by the input/output l/F 140, 
the judgment will be such that the analog content cannot 55 
be copied. 

[0269] The CGMS-A signal is a CGMS signal used in 
copy control of digital signals and applied to copy control 



of analog signals. It indicates that a content can be cop- 
ied freely or once or cannot be copied (copy-freely, 
copy-one-generation or copy-never). 
[0270] Therefore, if the CGMS-A signal is included in 
signal received by the input/output l/F 140 and means 
"copy-freely" or "copy-one-generation", it will be judged 
that the analog content can be copied. When the 
CGMS-A means "copy-never", the judgment will be 
such that the analog content cannot be copied. 
[0271] Further, in case neither the Macrovision signal 
nor the CGMS-A signal is included in signals received 
by the input/output l/F 1 40, it will be judged that the an- 
alog content cannot be copied. 

[0272] If the result of judgment in step S3312 is that 
the analog content cannot be copied, the recorder/play- 
er 1 00 will skip over steps S331 3 to S331 7 and exit the 
recording procedure. Therefore, in this case, the content 
will not be recorded to the recording medium 195. 
[0273] Also, if the result of judgment in step S331 2 is 
that the analog content can be copied, the recorder/ 
player goes to step S3313. Subsequently, in steps 
S3313 to S3317, similar operations to those in steps 
S322 to S326 in FIG. 3B are effected, whereby the con- 
tent is converted to a digital content, and then subjected 
to MPEG encoding, TS processing and encryption for 
recording to the recording medium. Here, the recorder/ 
player exits the recording procedure. 
[0274] Note that when the analog signals received by 
the input/output l/F 1 40 includes the CGMS-Asignal, the 
CGMS-A signal will also be recorded to the recording 
medium when recording the analog content to the re- 
cording medium. Namely, the CGMS-Asignal is record- 
ed in the place of the CCI or other information shown in 
FIG. 10. Generally, information meaning "copy-one- 
generation" is converted to "no-more-copies" for record- 
ing to prohibit more copies than a predetermined limit. 
However, such information conversion will not be effect- 
ed provided that there has been established for the sys- 
tem a rule that the copy control information "copy-one- 
generation" shall not be converted to "no-more-copies" 
for recording but shall betaken as "no-more-copies". 

[Copy control in data playback] 

[0275] Next, the content is read from the recording 
medium, and outputted as a digital content to outside as 
shown in the flow chart in FIG. 34A. The operations 
shown in FIG. 34A will be described. First in steps 
S3401, 3402 and S3403, there will be effected similar 
operations to those in steps S401, S402 and S403 in 
FIG. 4A, whereby the encrypted content read from the 
recording medium is decrypted by the cryptography unit 
150 and subjected to TS processing. After subjected to 
these processes, the digital content is supplied to the 
input/output l/F 1 20 via the bus 110. 
[0276] In step S3404, the input/output l/F 1 20 judges 
whether the digital content supplied thereto can be cop- 
ied later. Namely, in case the digital content supplied to 
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the input/output l/F 120 includes no EMI or information 
indicative of a copy control status (copy control informa- 
tion) like the EMI, it will be judged that the content can 
be copied later. 

[0277] Also, in case the digital content supplied to the 
input/output l/F 120 includes EMI for example, namely, 
in case an EMI has been recorded in conformity to the 
DTCP standard during data recording, and if the EMI 
(recorded EMI) means "copy-freely", it will be judged 
that the digital content can be copied later. Also, when 
the EMI means "no-more-copies", it will be judged that 
the content cannot be copied later. 
[0278] It should be reminded that generally, the re- 
corded EMI does not means "copy-one-generation" and 
"copy-never" because an EMI meaning "copy-one-gen- 
eration" is converted to "no-more-copies" during data 
recording and a digital content having an EMI meaning 
"copy-never" will not be recorded to the recording me- 
dium. However, the EMI conversion will not be effected 
provided that there has been defined for the system a 
rule that the copy control information "copy-one-gener- 
ation" shall not be converted to "no-more-copies" for re- 
cording but shall betaken as "no-more-copies". 
[0279] If the result of judgment in step S3404 is that 
the content can be copied later, the input/output l/F 1 20 
goes to step S3405 where it will output the digital content 
to outside and exit the playback procedure. 
[0280] Also, if the result of judgment in step S3404 is 
that the content cannot be copied later, the input/output 
l/F 120 goes to step S3406 where it will output, accord- 
ing to the DTCP or the like, the digital content in such a 
form that can not be copied and exit the playback proce- 
dure. 

[0281 ] That is to say, in case the recorded EM I means 
"no-more-copies" as in the above (or if there has been 
defined for the system a rule that copy control informa- 
tion "copy-one-generation" for example shall not be con- 
verted to "no-more-copies" for recording but shall be 
taken as"no-more-copies" and the EMI recorded under 
this condition means "copy-one-generation"), the con- 
tent will be prohibited from being further copied. 
[0282] Thus, the input/output l/F 120 makes mutual 
authentication with a counterpart device according to 
the DTCP standard. If the counterpart device is a legal 
one (a device conforming to the DTCP standard herein), 
the input/output l/F 1 20 encrypts the digital content and 
outputs the data to outside. 

[0283] Next, for playing back the content from the re- 
cording medium and outputting the data as an analog 
content, the playback is effected as in the flow chart in 
FIG. 34B. The operations for the playback will be de- 
scribed with reference to FIG. 34B. In steps S3411 to 
S3415, similar operations to those in steps S421 to 
S425 in FIG. 4B are effected. That is, an encrypted con- 
tent is read, and subjected to decryption, TS processing, 
MPEG decoding and D/A conversion. An analog content 
thus provided is received by the input/output l/F 140. 
[0284] In step S3416, the input/output l/F 140 judges 



whether a content supplied thereto can be copied later. 
Namely, in case no copy control information is found re- 
corded along with the recorded content, it will be judged 
that the content can be copied later. 

5 [0285] In case EMI or copy control information has 
been recorded during content recording in conformity to 
the DTCP standard for example, and if the EMI or copy 
control information means "copy-freely", itwill bejudged 
that the content can be copied later. 

10 [0286] Also, in case the EMI or copy control informa- 
tion means "no-more-copies", or in case there has been 
defined for the system a rule that the copy control infor- 
mation "copy-one-generation" for example shall not be 
converted to "no-more-copies" for recording but shall be 

15 taken as "no-more-copies" and if the EMI or copy control 
information recorded under this condition means "copy- 
one-generation", itwill bejudged thatthe content cannot 
be copied later. 

[0287] Further, in case an analog content supplied to 
20 the input/output l/F 140 includes a CGMS-A signal, 
namely, in case the CGMS-A signal has been recorded 
along the content during data recording, and if the 
CGMS-A signal means "copy-freely", it will be judged 
that the analog content can be copied later. Also, when 
25 the CGMS-A signal means "copy-never", it will be 
judged that the analog content cannot be copied later. 
[0288] If the result of judgment in step S341 6 is that 
the analog content can be copied later, the input/output 
l/F 140 goes to step S3417 where it will output the an- 
30 alog signals supplied thereto as they are and exit the 
playback procedure. 

[0289] Also, if the result of judgment in step S341 6 is 
that the analog content cannot be copied later, the input/ 
output l/F 140 goes to step S3418 where it will output 

35 the analog content in such a form thatthe content cannot 
be copied, and exit the playback procedure. 
[0290] Namely, in case copy control information such 
as recorded EMI means "no-more-copies as in the 
above (alternatively, in case there has been defined for 

40 the system a rule that copy control information "copy- 
one-generation" for example shall not be converted 
to "no-more-copies" for recording but shall be taken 
as "no-more-copies" and if copy control information like 
an EMI recorded underthis condition means "copy-one- 

45 generation"), the content will be prohibited from be cop- 
ied any more. 

[0291 ] Thus, the input/output l/F 1 40 appends a Mac- 
rovision signal and a CGMS-A meaning "copy-never" to 
the analog content, and outputs the analog signal to out- 
50 side. 

Also in case recorded CGMS-A signal means "copy- 
never" for example, the content will be prohibited from 
being copied any more. Thus, the input/output l/F 140 
modifies the CGMS-A signal to "copy-never" and out- 
55 puts it along with the analog content to outside. 

[0292] As in the above, by controlling copying of a 
content while recording or playing back the content, it is 
possible to prevent the content from being copied be- 
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yond a permitted range for the content (illegal copy). 
[Construction of the data processor] 

[0293] Note that the aforementioned series of opera- 5 
tions can be done by a hardware or by a software. 
Namely, the cryptography unit 150 can be formed from 
an encryption/decryption LSI and also the cryptography, 
namely, the encryption/decryption, by the cryptography 
unit 1 50 can be done by having a general-purpose com- 10 
puter or a one-chip microcomputer execute a corre- 
sponding program. Similarly, the operations of the TS 
processor 300 can be done by a software. For effecting 
the series of operations for TS processing by a software, 
a program including the software is installed in a gener- 15 
al-purpose computer, one-chip microcomputer or the 
like. FIG. 35 shows an example construction of one em- 
bodiment of a computer in which the program for the 
series of operations is installed. 

[0294] The program can be prerecorded in a hard disc 20 
3505 and ROM 3503 as recording media incorporated 
in the computer. Alternatively, the program may be 
stored (recorded) provisionally or permanently in a re- 
movable recording medium 351 0 such as a floppy disc, 
CD-ROM (compact disc read-only memory), MO (mag- 25 
neto-optical) disc, DVD (digital versatile disc), magnetic 
disc, semiconductor memory or the like. Such a remov- 
able recording medium 3510 can be provided as a so- 
called package software. 

[0295] It should be reminded that the program can be 30 
installed from the aforementioned removable recording 
medium 351 0 to a computer, otherwise, transferred from 
a download site to the computer by a radio communica- 
tion network over a digital broadcasting satellite or trans- 
ferred to the computer over a cable via a network such 35 
as LAN (local area network), Internet or the like, the 
computer receives the program thus transferred by a 
communication unit 3508 thereof and install it into the 
built-in hard disc 3505. 

[0296] The computer incorporates a CPU (central 40 
processing unit) 3502 as shown. The CPU 3502 is con- 
nected to an input/output interface 351 1 via a bus 3501 . 
When the CPU 3502 is supplied with an instruction from 
an input unit 3507 operated by the user, such as a key- 
board, mouse or the like via the input/output interface 45 
3511, it executes the program stored in a ROM (read- 
only memory) 3503. 

[0297] Alternatively, the CPU 3502 loads, into a RAM 
(random-access memory) 3504 for execution, a pro- 
gram stored in the hard disc 3505, a program transferred 50 
from a satellite or network, received by the communica- 
tion unit 3508 and installed into the hard disc 3505 or a 
program read from the removable recording medium 
351 0 set in a drive 3509 and installed into the hard disc 
3505. 55 
[0298] Thus, the CPU 3502 makes operations as in 
the aforementioned flow charts or operations as in the 
aforementioned block diagrams. The CPU 3502 outputs 
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results of these operations from an output unit 3506 
such as an LCD (liquid crystal display) or speaker, or 
transmits them from the communication unit 3508, or 
records them to the hard disc 3505, via the input/output 
interface 3511 , as necessary. 

[0299] Note that the operations or processes to de- 
scribe a program which allows the computer to do a va- 
riety of operations may not always be done in the time 
sequence as in the flow charts but may include ones 
which are executed in parallel or individually (parallel 
processes or processes by objects, for example). 
[0300] The program may be a one which can be exe- 
cuted by a single computer or in a decentralized manner 
by a plurality of computers. Further, the program may 
be a one which can be transferred to a remote computer 
for execution. 

[0301] In the above, the present invention has been 
described concerning the example that a cryptography 
block formed from one-chip encryption/decryption LSI 
encrypts and decrypts a content. Note however that the 
content encryption/decryption block may also be a sin- 
gle software module which is to be executed by the CPU 
1 70 shown in FIGS. 1 and 2, for example. Similarly, the 
operations of the TS processor 300 may be done by a 
single software module which is to be executed by the 
CPU 170. 

[0302] In the foregoing, the present invention has 
been described in detail concerning the specific embod- 
iments thereof. However, it will be apparent that the em- 
bodiments can be modified or changed by those skilled 
in the art without departing from the scope and spirit of 
the present invention. Namely, since the present has 
been disclosed by way of example, so the embodiments 
should not limitatively be interpreted. The present inven- 
tion is essentially defined in the claims given later. 

Industrial Applicability 

[0303] The information recording/playback apparatus 
and method according to the present invention generate 
a block key for encrypting block data based on an ATS 
which is random data corresponding to a time when 
each packet arrives. So it is possible to generate a 
unique key which varies from one block to another, use 
a different encryption key for each block and thus en- 
hance the protection against data cryptanalysis. Also, 
by generating a block key based on the ATS, no area 
has to be secured in the recording medium for storage 
of an encryption key for each block and thus the main 
data area can be used more effectively. Furthermore, 
data other than the main data has not to be accessed 
during data recording or playback, and thus the data re- 
cording orplaybackcan be done with a higher efficiency. 



Claims 

1 . An information recorder for recording information to 
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a recording medium, the apparatus comprising: 

a transport stream processing means for ap- 
pending an arrival time stamp (ATS) to each of 
discrete transport packets included in a trans- 5 
port stream; and 

a cryptography means for generating a block 
key for encrypting a block data including more 
than one transport packet each having the ap- 
pended arrival time stamp (ATS) from a block 10 
seed which is additional information unique to 
the block data and including the arrival time 
stamp (ATS), and encrypting each block data 
with the block key thus generated; 
the data encrypted by the cryptography means 15 
being recorded to the recording medium. 

2. The apparatus according to claim 1 , wherein the 
cryptography means generates the block key for 
encrypting the block data from a block seed which 20 
is additional information unique to the block data 
and including the arrival time stamp (ATS) append- 
ed to a leading one of the plurality of transport pack- 
ets included in the block data. 

25 

3. The apparatus according to claim 1 , wherein the 
cryptography means generates a title-unique key 
from a master key stored in the information record- 
er, disc ID being a recording medium identifier 
unique to a recording medium and a title key unique 30 
to data to be recorded to the recording medium, and 
generates the block key from the title-unique key 
and block seed. 

4. The apparatus according to claim 1 , wherein the 35 
cryptography means generates a disc ID being a 
recording medium identifier unique to a recording 
medium and atitle key unique to data to be recorded 

to the recording medium, and stores them into the 
recording medium. 40 

5. The apparatus according to claim 1 , wherein the 
block seed includes copy control information in ad- 
dition to the arrival time stamp (ATS). 

45 

6. The apparatus according to claim 1 , wherein the 
cryptography means encrypts, with the block key in 
the encryption of the block data, only data included 
in the block data and excluding data in a leading 
area including a block seed of the block data. 50 

7. The apparatus according to claim 1 , wherein the 
cryptography means generates a title-unique key 
from a master key stored in the information record- 
er, disc ID being a recording medium identifier 55 
unique to a recording medium and a title key unique 

to data to be recorded to the recording medium, 
takes the thus-generated title-unique key as a key 



for an encryption function, places the block seed in- 
to the encryption function, and outputs a result of 
the placement as a block key. 

8. The apparatus according to claim 1 , wherein the 
cryptography means generates a title-unique key 
from a master key stored in the information record- 
er, disc ID being a recording medium identifier 
unique to a recording medium and a title key unique 
to data to be recorded to the recording medium, 
places the title-unique key thus generated and 
block seed into a one-way function, and outputs a 
result of the placement as a block key. 

9. The apparatus according to claim 1 , wherein the 
cryptography means generates a device-unique 
key from any of an LSI key stored in an LSI included 
in the cryptography means, device key stored in the 
information recorder, medium key stored in the re- 
cording medium and a drive key stored in a drive 
unit for the recording medium or a combination of 
these keys, and generates a block key for encrypt- 
ing the block data from the device-unique key thus 
generated and block seed. 

10. The apparatus according to claim 1, wherein the 
cryptography means encrypts block data with the 
block key according to a DES algorithm. 

11. The apparatus according to claim 1, further com- 
prising an interface means for receiving information 
to be recorded to a recording medium, and identi- 
fying copy control information appended to each of 
packets included in the transport stream to judge, 
based on the copy control information, whether or 
not recording to the recording medium is allowed. 

12. The apparatus according to claim 1, further com- 
prising an interface means for receiving information 
to be recorded to a recording medium, and identi- 
fying 2-bit EMI (encryption mode indicator) as copy 
control information to judge, based on the EMI, 
whether or not recording to the recording medium 
is allowed. 

13. An information player for playing back information 
from a recording medium, the apparatus compris- 
ing: 

a cryptography means for decrypting encrypted 
data recorded in the recording medium by gen- 
erating a block key for decrypting encrypted da- 
ta of a block data having an arrival time stamp 
(ATS) appended to each of a plurality of trans- 
port packets from a block seed which is addi- 
tional information unique to the block data and 
including the arrival time stamp (ATS), and de- 
crypting each block data with the block key thus 
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generated; and 

a transport stream processing means for con- 
trolling data output on the basis of the arrival 
time stamp (ATS) appended to each of the plu- 
rality of transport packets included in the block 
data having been decrypted by the cryptogra- 
phy means. 

14. The apparatus according to claim 13, wherein the 
cryptography means generates the block key for 
decrypting the block data from a block seed which 
is additional information unique to the block data 
and including the arrival time stamp (ATS) append- 
ed to a leading one of the plurality of transport pack- 
ets included in the block data. 

15. The apparatus according to claim 13, wherein the 
cryptography means generates a title-unique key 
from a master key stored in the information player, 
disc ID being a recording medium identifier unique 
to a recording medium and a title key uniqueto data 
to be recorded to the recording medium, and gen- 
erates the block key from the title-unique key and 
block seed. 

16. The apparatus according to claim 13, wherein the 
block seed includes copy control information in ad- 
dition to the arrival time stamp (ATS). 

17. The apparatus according to claim 13, wherein the 
cryptography means decrypts, with the block key, 
only data included in the block data and excluding 
data in a leading area including a block seed of the 
block data. 

18. The apparatus according to claim 13, wherein the 
cryptography means, generates a title-unique key 
from a master key stored in the information player, 
disc ID being a recording medium identifier unique 
to a recording medium and a title key uniqueto data 
to be recorded to the recording medium, takes the 
thus-generated title-unique key as a key for an en- 
cryption function, places the block seed into the en- 
cryption function, and outputs a result of the place- 
ment as a block key. 

19. The apparatus according to claim 13, wherein the 
cryptography means generates a title-unique key 
from a master key stored in the information player, 
disc ID being a recording medium identifier unique 
to a recording medium and a title key uniqueto data 
to be recorded to the recording medium, places the 
title-unique key thus generated and block seed into 
a one-way function, and outputs a result of the 
placement as a block key. 

20. The apparatus according to claim 13, wherein the 
cryptography means generates a device-unique 



key from any of an LSI key stored in an LSI included 
in the cryptography means, device key stored in the 
information player, medium key stored in the re- 
cording medium and a drive key stored in a drive 
5 unit for the recording medium or a combination of 

these keys, and generates a block key for decrypt- 
ing the block data from the device-unique key thus 
generated and block seed. 

10 21. The apparatus according to claim 13, wherein the 
cryptography means, decrypts block data with the 
block key according to a DES algorithm. 

22. The apparatus according to claim 13, further corn- 
's prising an interface means for receiving information 

to be recorded to a recording medium, and identi- 
fying copy control information appended to each of 
packets included in the transport stream to judge, 
based on the copy control information, whether or 
20 not playback from the recording medium is allowed. 

23. The apparatus according to claim 13, further com- 
prising an interface means for receiving information 
to be played back from a recording medium, and 

25 identifying 2-bit EMI (encryption mode indicator) as 
copy control information to judge, based on the EM I , 
whether or not playback the recording medium is 
allowed. 

30 24. A method for recording, information to a recording 
medium, the method comprising the steps of: 

appending an arrival time stamp (ATS) to each 
of discrete transport packets included in a 
35 transport stream; and 

generating a block key for encrypting a block 
data including more than one transport packet 
each having the appended arrival time stamp 
(ATS) from a block seed which is additional in- 
40 formation unique to the block data and includ- 

ing the arrival time stamp (ATS), and encrypting 
each block data with the block key thus gener- 
ated; 

the data encrypted in the cryptographic step be- 
45 jng recorded to the recording medium. 

25. The method according to claim 24, wherein in the 
cryptographic step, the block key for encrypting the 
block data is generated from a block seed which is 
50 additional information unique to the block data and 
including the arrival time stamp (ATS) appended to 
a leading one of the plurality of transport packets 
included in the block data. 

55 26. The method according to claim 24, wherein in the 
cryptographic step; a title-unique key is generated 
from a master key stored in the information record- 
er, disc ID being a recording medium identifier 
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unique to a recording medium and a title key unique 
to data to be recorded to the recording medium, and 
the block key is generated from the title-unique key 
and block seed. 

5 

27. The method according to claim 24, further compris- 
ing the step of generating a disc ID being. a record- 
ing medium identifier unique to a recording medium 
and a title key unique to data to be recorded to the 
recording medium, and storing them into the record- 10 
ing medium. 

28. The method according to claim 24, wherein in the 
cryptographic step, only data included in the block 
data and excluding data in a leading area including 15 
a block seed of the block data is encrypted with the 
block key in the encryption of the block data. 

29. The method according to claim 24, wherein in the 
cryptographic step, a title-unique key is generated 20 
from a master key stored in the information record- 
er, disc ID being a recording medium identifier 
unique to a recording medium and a title key unique 

to data to be recorded to the recording medium, the 
title-unique key thus generated is taken as a key for 25 
an encryption function, the block seed is placed into 
the encryption function, and a result of the place- 
ment is outputted as a block key. 

30. The method according to claim 24, wherein in the 30 
cryptographic step, a title-unique key is generated 
from a master key stored in the information record- 
er, disc ID being a recording medium identifier 
unique to a recording medium and a title key unique 

to data to be recorded to the recording medium, the 35 
title-unique key thus generated and block seed are 
placed into a one-way function, and a result of the 
placement is outputted as a block key. 

31. The method according to claim 24, wherein in the 40 
cryptographic step, a device-unique key is generat- 
ed from any of an LSI key stored in an LSI included 

in the cryptography means, device key stored in an 
information recorder, medium key stored in the re- 
cording medium and a drive key stored in a drive 45 
unit for the recording medium or a combination of 
these keys, and a block key for encrypting the block 
data is generated from the device-unique key thus 
generated and the block seed. 

50 

32. The method according to'claim 24, wherein in the 
cryptographic step, the encryption of block data with 
the block key is made according to a DES algorithm. 

33. The method according to claim 24, further compris- 55 
ing the step of identifying copy control information 
appended to each of packets included in the trans- 
port stream to judge, based on the copy control in- 



formation, whether or not recording to the recording 
medium is allowed. 

34. The method according to claim 24, further compris- 
ing the step of identifying 2-bit EMI (encryption 
mode indicator) as copy control information to 
judge, based on the EMI, whether or not recording 
to the recording medium is allowed. 

35. A method for playing back information from a re- 
cording medium, the method comprising the steps 
of: 

generating a block key for decrypting encrypted 
data in a block data having an arrival time 
stamp (ATS) appended to each of a plurality of 
transport packets from a block seed which is 
additional information unique to the block data 
and including the . arrival time stamp (ATS), 
and decrypting each block data with the block 
key thus generated; and 
processing a transport stream processing 
means to control data output on the basis of the 
arrival time stamp (ATS) appended to each of 
the plurality of transport packets included in the 
block data having been decrypted in the de- 
crypting step. 

36. The method according to claim 35, wherein in the 
decrypting step, the block key for decrypting the 
block data is generated from a block seed which is 
additional information unique to the block data and 
including the arrival time stamp (ATS) appended to 
a leading one of the plurality of transport packets 
included in the block data. 

37. The method according to claim 35, wherein in the 
decrypting step, a title-unique key is generated from 
a master key stored in the information player, disc 
ID being a recording medium identifier unique to a 
recording medium and a title key unique to data to 
be recorded to the recording medium, and the block 
key is generated from the title-unique key and block 
seed. 

38. The method according to claim 35, wherein in the 
decrypting step, only data included in the block data 
and excluding data in a leading area including a 
block seed of the block data is decrypted with the 
block key in the encryption of the block data. 

39. The method according to claim 35, wherein in the 
decrypting step, a title-unique key is generated from 
a master key stored in the information player, disc 
ID being a recording, medium identifier unique to a 
recording medium and a title key unique to data to 
be recorded to the recording medium, the. title- 
unique key thus generated is taken as a key for an 
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encryption function, the block seed is placed into 
the encryption function, and a result of the place- 
ment, is outputted as a block key. 

40. The method according to claim 35, wherein in the. 
decrypting step, a title-unique key is generated from 
a master key stored in the information player, disc 
ID being a recording medium identifier unique to a 
recording medium and a title key unique to data to 
be recorded to the recording medium, the title- 
unique key thus generated and block seed are 
placed into a one-way function, and a result of the 
placement is outputted as a block key. 



the computer program comprising the steps of: 

appending an arrival time stamp (ATS) to each 
of discrete transport packets included in a 
5 transport stream; and 

generating a block key for encrypting a block 
data including more than one transport packet 
each having the appended arrival time stamp 
(ATS) from a block seed which is additional in- 
fo formation unique to the block data and includ- 
ing the arrival time stamp (ATS), and encrypting 
each block data with the block key thus gener- 
ated. 



41. The method according to claim 35, wherein in the 
decrypting step, a device-unique key is generated 
from any of an LSI key stored in an LSI included in 
the cryptography means, device key stored in the 
information player, medium key stored in the re- 
cording medium and a drive key stored in a drive 
unit for the recording medium or a combination of 
these keys, and a block key for decrypting the block 
data is generated from the device-unique key thus 
generated and block seed. 

42. The method according to claim 35, wherein in the 
decrypting step, the block data decryption with the 
block key is made according to a DES algorithm. 

43. The method according to claim 35, further compris- 
ing the step of identifying copy control information 
appended to each of packets included in the. trans- 
port stream to judge, based on the copy control in- 
formation, whether or not playback from the record- 
ing medium is allowed. 



15 47. A program serving medium which serves a compu- 
ter program under which playback of information 
from a recording medium is done in a computer sys- 
tem, the computer program comprising the steps of: 



20 generating a block key for decrypting encrypted 

data in a block data having an arrival time 
stamp (ATS) appended to each of a plurality of 
transport packets from a block seed which is 
additional information unique to the block data 

25 and including the arrival time stamp (ATS), and 

decrypting each block data with the block key 
thus generated; and 

processing a transport stream to control data 
output on the basis of the arrival time stamp 
30 (ATS) appended to each of the plurality of trans- 

port packets included in the block data having 
been decrypted in the cryptographic step. 



44. The method according to claim 35, further compris- 
ing the step of identifying 2-bit EMI (encryption 
mode indicator) as copy control information to 
judge, based on the EMI, whether or not playback 40 
from the recording medium is allowed. 

45. A recording medium having recorded therein a 
block data including more than one packet included 

in a transport stream and having an arrival time 45 
stamp (ATS) appended to each of the packets, the 
block data including: 

an unencrypted data part having a block seed 
including the arrival time stamp (ATS) from 50 
which there is generated a block key for en- 
crypting the block data; and 
an encrypted data part having been encrypted 
with the block key. 

55 

46. A program serving medium which serves a compu- 
ter program under which recording of information to 
a recording medium is done in a computer system, 
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